Sharding-JDBC范围分表失效：如何排查MyRangeShardingAlgorithm未命中及SQL未命中分表问题？

Sharding-JDBC范围分表失效，调查Myrangeshardingalgorithm未命中和SQL未命中分表问题

本文分析了Sharding-JDBC范围分表失败的原因，并提供了调查步骤。

问题描述： SpringBoot(基于若依框架)+MySQL应用，使用Sharding-JDBC进行范围分表，但分表失效，SQL查询未命中分表，MyrangeShardingAlgorithm断点未命中，SQL直接查询逻辑表lyg_tsvol。

排查方向：

以下方面可能导致问题：

1. 配置错误： 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配置发生冲突。

2. 算法问题： Myrangeshardingalgorithmgettablenames方法负责生成表名列表。 应仔细检查该方法的逻辑，以确保它能够根据起始日期和结束日期正确生成所有合格的表名(如lyg_tsvol_202308, lyg_tsvol_202309）。 特别注意边界条件的处理，确保正确处理开始和结束的月份。 当前逻辑可能只处理before关系，需要考虑等于的情况。 日志打印有助于检查生成的表名是否正确。

3. 数据源配置： ShardingDataSource方法创建了ShardingDataSourceFactory。 确保数据源正确注入DynamicdataSource，DynamicdataSource用于应用，而不是原始数据源。 Druidconfig中的多数据源配置需要确保ShardingDataSource正确配置并与DataSourcetype相关联.SHARDING。

4. SQL语句： SELECT count(0) FROM lyg_tsvol a ... 直接查询逻辑表lyg___tsvol，说明分片规则没有生效。 这可能是由于配置错误或算法问题。 若分片规则正确，且createtime字段值在规则范围内，Sharding-JDBC应自动路由到正确的物理表。

5. 主要生成策略： 配备SNOWFLAKE主键生成器的createtablerule方法。 确保生成器正确配置和运行。

排查建议：

• 打印日志： 在Myrangeshardingalgorithm和Mypreciseshardingalgorithm中添加更多日志，打印availabletargetnames，shardingValue，rangeShardingValue等变量值，跟踪数据流。
• 简化测试： 创建一个简单的测试用例，只包括一个表和一个简单的分片规则，以验证Sharding-JDBC是否正常工作。
• 检查表结构： 根据分片规则确认数据库中是否有物理表。

Sharding-JDBC分表失效的原因可以通过仔细检查以上几点并结合日志信息来找到。

以上是Sharding-JDBC范围分表的故障：如何检查MyRangeShardingAlgorithm未命中和SQL未命中分表的问题？有关详细信息，请关注图灵教育的其他相关文章！