Sharding-JDBC范围分表失效原因分析及排查步骤
本文针对Sharding-JDBC范围分表失效问题提供详细的排查思路。 假设已知lyg_tsvol和lyg_vehicle两表使用范围分表策略，并自定义了MyRangeShardingAlgorithm。
首先，仔细检查YAML配置，特别是actual-data-nodes配置。 复杂的配置（例如文中提到的lyg_tsvol$->{2023..2024}0$->{1..9},sharding.lyg_tsvol$->{2022..2024}1$->{0..2}）容易出错。建议采用更清晰的命名方式，例如lyg_tsvol_${year}${month}，并确保其与实际物理表名完全一致。
其次，重点关注自定义分片算法MyRangeShardingAlgorithm。 getTableNames方法生成的年月字符串必须与doSharding方法中拼接的逻辑表名精确匹配，最终结果要与实际物理表名完全一致。 如果物理表名与预期不符，分表将失效。 文中提到断点无法进入doSharding方法，这表明Sharding-JDBC可能根本没有调用自定义算法。 这可能是以下几个原因造成的：
-
数据源配置错误: 彻底检查ShardingDataSourceConfig类中shardingDataSource方法的配置，确保sharding数据源正确配置，连接信息无误，且shardingDataSource Bean 正确创建并注入到dynamicDataSource中。
-
sql语句错误: 直接使用逻辑表名（例如select count(0) FROM lyg_tsvol a …）会导致分表失效。 确保sql语句使用正确的物理表名，或者Sharding-JDBC能够根据createtime列的值自动路由到正确的物理表。 建议打印实际执行的SQL语句进行检查。
-
Sharding-JDBC版本及依赖冲突: 检查Sharding-JDBC版本是否与其他依赖库冲突。 尝试升级或降级Sharding-JDBC，并确保所有依赖版本兼容。
-
createtime字段类型和值: 确认createtime字段类型为timestamp或DATETIME，且值正确。 错误的createtime值会使分表算法出错。
-
actual-data-nodes配置错误: 再次仔细检查actual-data-nodes配置，确保其与实际物理表名完全匹配，且数据源配置正确。 任何配置错误都会导致Sharding-JDBC无法找到正确的物理表。
排查步骤建议：
- 验证数据源配置: 首先验证数据源配置的正确性，确保连接数据库成功。
- 检查SQL语句: 打印实际执行的SQL语句，检查是否使用了正确的表名。
- 调试自定义算法: 在MyRangeShardingAlgorithm中添加更多日志，打印输入参数和生成的表名，以便跟踪执行流程。
- 检查物理表是否存在: 确认所有根据配置生成的物理表是否存在于数据库中。
- 简化配置: 尝试简化YAML配置，使其更易于理解和调试。
- 版本兼容性: 检查Sharding-JDBC及其依赖库的版本兼容性。
如果以上步骤仍无法解决问题，请提供以下信息以便进一步分析：
- YAML配置完整内容
- MyRangeShardingAlgorithm的完整代码
- 实际执行的SQL语句
- 相关的日志信息
- 数据库结构信息
通过系统地排查这些方面，就能有效定位并解决Sharding-JDBC范围分表失效的问题。
