Sharding-JDBC范围分表失效：排查MyRangeShardingAlgorithm未命中及sql未命中分表问题
本文分析Sharding-JDBC范围分表失败的原因，并提供排查步骤。
问题描述： SpringBoot（基于若依框架）+mysql应用，使用Sharding-JDBC进行范围分表，但分表失效，SQL查询未命中分表，MyRangeShardingAlgorithm断点未命中，SQL直接查询逻辑表lyg_tsvol。
排查方向：
以下几个方面可能导致问题：
-
配置错误： yml配置文件中的分片规则可能存在问题。例如，actual-data-nodes中的配置 lyg_tsvol$->{2023..2024}0$->{1..9},sharding.lyg_tsvol$->{2022..2024}1$->{0..2} （以及lyg_vehicle表的类似配置）的表名生成逻辑可能与预期不符。请仔细检查配置，确保其与实际表名（例如lyg_tsvol_202301）匹配。 注意$->符号的使用，以及年份和月份范围的准确性。 createTableRule方法中动态生成的表名规则（例如tableName + “$->{2023..” + currentYear + “}0$->{6..” + currentMonth + “}”）可能与yml配置冲突。
-
算法问题： MyRangeShardingAlgorithm的getTableNames方法负责生成表名列表。 需仔细检查该方法逻辑，确保其能根据起始日期和结束日期正确生成所有符合条件的表名（例如lyg_tsvol_202308, lyg_tsvol_202309）。 特别注意边界条件处理，确保起始和结束月份都能正确处理。 当前逻辑可能只处理了before关系，需要考虑等于的情况。 日志打印有助于检查生成的表名是否正确。
-
数据源配置： shardingDataSource方法创建了ShardingDataSourceFactory。 确保该数据源被正确注入到DynamicDataSource中，并且应用中使用的是DynamicDataSource，而非原始数据源。 DruidConfig中的多数据源配置需要确保shardingDataSource被正确配置并关联到DataSourceType.SHARDING。
-
sql语句： select count(0) FROM lyg_tsvol a … 直接查询逻辑表lyg_tsvol，说明分片规则未生效。 这可能是由于配置错误或算法问题。 如果分片规则正确且createtime字段值在规则范围内，Sharding-JDBC应该自动路由到正确的物理表。
-
主键生成策略： createTableRule方法配置了SNOWFLAKE主键生成器。 确保该生成器已正确配置和运行。
排查建议：
- 打印日志： 在MyRangeShardingAlgorithm和MyPreciseShardingAlgorithm中添加更多日志，打印availableTargetNames，shardingValue，rangeShardingValue等变量的值，追踪数据流向。
- 简化测试： 创建简单的测试用例，只包含一个表和简单的分片规则，验证Sharding-JDBC是否正常工作。
- 检查表结构： 确认数据库中是否存在根据分片规则生成的物理表。
通过仔细检查以上几点并结合日志信息，即可找到Sharding-JDBC分表失效的原因。
