JeecgBoot项目集成ShardingSphere分库分表问题分析

问题背景

在JeecgBoot 3.7.3版本(基于Spring Boot 3.1.5)中集成ShardingSphere分库分表组件时，开发者遇到了一个典型的堆栈溢出错误。当调用测试接口时，系统抛出jakarta.servlet.ServletException: Handler dispatch failed: java.lang.StackOverflowError异常。

错误现象分析

从错误日志可以看出，这是一个典型的无限递归调用导致的堆栈溢出问题。在ShardingSphere集成过程中，这种问题通常发生在以下场景：

1. 数据源代理层与ORM框架(如MyBatis)的交互过程中
2. 分片算法实现类存在循环依赖
3. Spring容器初始化时的Bean依赖循环

配置分析

开发者提供的ShardingSphere配置显示：

1. 使用了单数据源(ds0)配置
2. 对sys_log表进行了水平分表(分为sys_log0和sys_log1)
3. 采用CLASS_BASED方式实现分片算法(StandardModTableShardAlgorithm)

根本原因

经过深入分析，这个问题可能由以下几个因素导致：

1. 版本兼容性问题：Spring Boot 3.x与ShardingSphere的某些版本存在兼容性问题
2. 自动配置冲突：Spring Boot的自动配置与ShardingSphere的配置可能产生冲突
3. 分片算法实现：自定义的StandardModTableShardAlgorithm可能存在递归调用

解决方案

根据社区反馈，有效的解决方案是：

1. 手动管理ShardingSphere JDBC依赖：不使用Spring Boot Starter提供的自动配置，而是手动管理ShardingSphere JDBC的版本和配置
2. 检查分片算法实现：确保StandardModTableShardAlgorithm类没有循环调用问题
3. 依赖隔离：将ShardingSphere相关配置放在独立的配置类中，避免与Spring Boot自动配置冲突

实施建议

对于需要在JeecgBoot项目中集成ShardingSphere的开发者，建议：

1. 明确ShardingSphere版本与Spring Boot 3.x的兼容性矩阵
2. 采用分步骤集成方式，先验证基础功能再添加复杂分片规则
3. 对关键组件(如分片算法)进行单元测试
4. 监控应用启动过程中的Bean初始化顺序

总结

ShardingSphere作为成熟的分库分表解决方案，在集成过程中仍需注意框架版本兼容性和配置细节。特别是在Spring Boot 3.x环境下，更应谨慎处理自动配置与手动配置的关系。通过合理的依赖管理和配置隔离，可以避免此类堆栈溢出问题。