SpringBoot整合Sharding-JDBC避坑指南：从配置到压测的全链路实践 1. 环境准备与依赖配置当我在实际项目中第一次尝试将Sharding-JDBC整合到SpringBoot时发现版本兼容性是个隐形炸弹。SpringBoot 3.x对JDK17有强制要求而Sharding-JDBC 5.5.0恰好完美支持。这里分享我的POM配置经验dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc/artifactId version5.5.0/version exclusions exclusion groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-test-util/artifactId /exclusion /exclusions /dependency特别注意要排除test-util依赖这个包在运行时会导致类冲突。有次凌晨三点排查问题时发现控制台不断报ClassNotFoundException最后发现就是这个测试工具包在作怪。2. 配置文件的双层结构Sharding-JDBC的配置分为两层就像俄罗斯套娃外层application.yml配置数据源驱动内层shardingsphere-config.yaml定义分片规则application.yml关键配置spring: datasource: driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver url: jdbc:shardingsphere:classpath:shardingsphere-config.yaml这里有个隐藏大坑如果同时配置了Hikari连接池参数ShardingSphere会直接忽略。有次性能测试发现连接数始终上不去花了半天才发现是Hikari配置被静默丢弃了。3. 分片算法选择实战3.1 内置算法翻车现场最初尝试使用内置HASH_MOD算法shardingAlgorithms: integral_package_order_table_hash_mod: type: HASH_MOD props: sharding-count: 16结果启动直接报错integral_package_order tables sharding configuration can not use auto sharding algorithm。原来5.5.0版本对自动算法做了限制必须显式指定INLINE或自定义算法。3.2 自定义算法实现最终采用CLASS_BASED方式实现public class TableHashModShardingAlgorithm implements StandardShardingAlgorithmLong { Override public String doSharding(CollectionString availableTargetNames, PreciseShardingValueLong shardingValue) { long id shardingValue.getValue(); int mod (int) (id % availableTargetNames.size()); return availableTargetNames.stream() .skip(mod).findFirst() .orElseThrow(() - new IllegalArgumentException(分片失败)); } }在配置中需要指定全限定类名shardingAlgorithms: integral_package_order_table_hash_mod: type: CLASS_BASED props: algorithmClassName: com.example.TableHashModShardingAlgorithm sharding-count: 164. JSON序列化异常处理整合后最诡异的bug是接口突然返回XML格式。查源码发现Sharding-JDBC 5.5.0自带jackson-dataformat-xml会劫持SpringBoot的消息转换器。解决方案是在WebMvcConfigurer中强制指定JSON优先级Override public void configureContentNegotiation(ContentNegotiationConfigurer configurer) { configurer.defaultContentType(MediaType.APPLICATION_JSON) .ignoreAcceptHeader(true); }这个坑我踩了整整一天各种尝试排除依赖未果最后在ShardingSphere的GitHub Issue里找到这个方案。5. 压测验证与调优使用JMeter进行分片效果验证时发现三个关键点线程组配置建议使用100线程×10循环Ramp-up时间设为0数据分布检查执行后查询各分表数据量SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema your_db AND table_name LIKE integral_package_order_%;性能瓶颈定位发现单表数据超过500万时分片键查询效率下降明显需要添加对应索引ALTER TABLE integral_package_order_0 ADD INDEX idx_user_id (user_id);6. 生产环境注意事项配置中心集成建议通过SPI机制将配置迁移到Nacos修改配置无需重启影子表策略压测时启用影子库配置避免污染生产数据SQL限制不支持跨分片JOIN复杂查询需要改造为多次单查监控接入配合Prometheus暴露ShardingSphere的metrics指标有次线上事故就是因为开发同学写了跨分片GROUP BY导致全库表扫描。后来我们通过SQL解析器做了拦截这类问题要提前防范。