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分表失效的原因。
