Sharding-JDBC范围分表失效排查指南
本文针对Sharding-JDBC范围分表失败问题,提供详细的排查步骤和解决方案。问题表现为:使用范围分片算法(MyRangeShardingAlgorithm)时,SQL语句未被路由到实际分表,而是直接查询逻辑表。
可能原因及排查方法:
1. 算法逻辑及日志验证:
首先,检查MyRangeShardingAlgorithm
的doSharding
方法。该方法应打印范围区间和路由表信息。 通过日志确认该方法是否被调用。若日志中未出现预期信息,则说明doSharding
方法未被执行,问题可能源于配置错误。
2. 配置文件与表名匹配:
仔细核对yml
配置文件中actual-data-nodes
的配置,确保表名与数据库中表名完全一致(包括大小写和下划线)。 例如,配置lyg_tsvol-${2023..2024}0-${1..9},sharding.lyg_tsvol-${2022..2024}1-${0..2}
生成的表名规则必须与MyRangeShardingAlgorithm
中生成的表名规则完全匹配。任何不一致都可能导致分表失效。
3. createtime
字段数据类型及数据:
MyPreciseShardingAlgorithm
和MyRangeShardingAlgorithm
都依赖createtime
字段。验证lyg_tsvol
和lyg_vehicle
表的createtime
字段数据类型是否为Timestamp
,且数据内容符合预期。数据类型不符、createtime
字段为空或格式异常都会影响分片算法。
4. Sharding-JDBC及数据源配置:
检查ShardingDataSourceConfig
类中createDataSource
方法的配置,特别是ShardingRuleConfiguration
,确认MyPreciseShardingAlgorithm
和MyRangeShardingAlgorithm
已正确注册。 同时,检查多数据源配置(例如DruidConfig
),确保Sharding数据源(shardingDataSource
)已正确添加到DynamicDataSource
,并在SQL执行时被正确选择。
5. SQL语句及查询条件:
SQL语句SELECT count(0) FROM lyg_tsvol a LEFT JOIN mst_gcz b ON a.devcode = b.equipment_code WHERE date_format(a.createtime, '%Y-%m-%d %H:%i') BETWEEN date_format(?, '%Y-%m-%d %H:%i') AND date_format(?, '%Y-%m-%d %H:%i')
使用了date_format
函数处理createtime
字段。这可能与分表策略冲突。建议尝试直接使用createtime
列作为查询条件。
6. 依赖版本兼容性:
检查所有Sharding-JDBC相关依赖的版本是否兼容,是否存在版本冲突。
通过以上步骤,结合日志信息,可以有效定位并解决Sharding-JDBC分表失效问题。 建议逐一排查,并根据实际情况进行调整。