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分表失效問題。 建議逐一排查，并根據實際情況進行調整。
