1.分库分表的需求背景
单表数据量超过千万级后，查询性能下降；单库连接数有限。分库分表将数据水平拆分到多个数据库和表中。但业务代码需要知道具体访问哪个库哪个表，侵入性强。ShardingSphere是一套开源的分布式数据库中间件，完全由Java实现，通过拦截JDBC层SQL，自动路由到目标数据源。
参考：https://www.xrzqr.cn/category/city-forecast.html
2.ShardingSphere-JDBC的工作原理
它以JAR包形式集成在应用内，重写DataSource接口，解析SQL中的分片键（如order_id），根据分片算法（如order_id%4）计算出目标库和表，再改写SQL（如添加表别名、调整范围查询），最后执行并聚合结果。对业务代码透明，只需修改DataSource配置。
3.分片策略与分布式事务
分片键：通常选择查询频率高的字段（如user_id、order_id）。
分片算法：取模、哈希、范围、复合分片。
分布式事务：ShardingSphere支持XA（Atomikos）和柔性事务（SEATA），保证跨库操作的ACID。
4.读写分离与影子库
ShardingSphere也支持主从读写分离：写SQL走主库，读SQL走从库，并内置负载均衡。影子库（ShadowDB）用于压测流量路由，不影响生产数据。
参考：https://www.xrzqr.cn/category/national-weather.html
5.案例：电商订单表的分库分表
某电商订单系统，订单表每天新增200万行。计划分16个库，每个库64张表（共1024张表）。分片键为order_id（雪花算法生成，包含时间戳）。使用ShardingSphere-JDBC配置：
default-database-strategy：order_id%16确定数据库。
table-strategy：order_id%64确定表。
对于查询用户订单（需user_id分片），使用复合分片，同时支持order_id和user_id，避免全路由。
上线后，单条查询平均耗时<2ms，范围查询通过IN拆解为多个单分片查询，性能提升10倍。
6.SQL限制与注意事项
不支持跨库JOIN（除非绑定表，即相同分片键）。
ORDERBY、GROUPBY会收集所有分片结果再聚合，大量数据时性能差。
不支持INSERTINTO...SELECT等复杂语句。
分布式序列（雪花算法）内置支持。
7.与MyCAT、Vitess对比
MyCAT：独立代理，性能有损耗，但跨语言。
Vitess：基于MySQL协议代理，功能强大，但部署复杂。
ShardingSphere-JDBC：无代理，性能好，适合Java技术栈。
8.总结
ShardingSphere是Java生态中分库分表的首选方案。它在JDBC层透明地解决了水平扩展问题，让开发者可以继续使用熟悉的JPA或MyBatis操作多数据源。对于数据量持续增长的应用，这是必备的中间件。
参考：https://www.xrzqr.cn
