分库分表核心是逻辑表到物理库表的可维护映射，推荐分库（用户ID取模）+分表（时间年份）双维度；平滑扩容分两阶段：新节点路由写入、工具迁移校验；需避坑：分片键非空、禁跨片JOIN/LIMIT、时间分片须预建表；配置优先YAML+自定义算法。
分库分表的核心设计：从逻辑到物理的映射
ShardingSphere 的核心是将 SQL 中的逻辑表（如 order）按规则路由到多个真实数据库和表（如 ds0.order_0, ds1.order_1）。关键不是“怎么切”，而是“切得可维护、可演进”。推荐采用 分库 + 分表双维度，例如：按用户 ID 取模分库（8 库），再按订单创建时间年份分表（order_2023, order_2024）。这样既避免单库瓶颈，又利于冷热数据隔离。
平滑扩容的底层逻辑：避免停机与数据迁移冲突
ShardingSphere 本身不自动搬数据，但提供 读写分离 + 动态配置 + 数据一致性保障 三件套支撑平滑过程。扩容本质是两阶段：
- 第一阶段（上线新节点）：新增库 ds2、ds3，配置 ShardingSphere 让新写入流量按新分片算法（如取模数从 8 扩到 16）路由过去，旧库保持只读；
- 第二阶段（迁移+校验）：用 ShardingSphere-Scaling 工具并行迁移历史数据，同时开启 影子表比对 或业务层双查比对（查旧路径 + 新路径），确认无误后切换读流量。
实战中必须避开的三个坑
• 分片键不能为 NULL 或空字符串：否则路由失败，建议在 MyBatis-Plus 拦截器或 Service 层做非空校验并抛明确异常。
• 跨分片 JOIN 和 ORDER BY LIMIT 尽量避免：ShardingSphere 会合并结果，性能差且内存易溢出；改用应用层聚合或冗余字段（如把用户昵称冗余到订单表）。
• 时间分片需预建表：比如按月分表，必须提前建好 order_202501 ~ order_202512，ShardingSphere 不自动建表，否则插入报错。
配置落地要点：YAML + 自定义算法够用不臃肿
不用硬编码分片逻辑，优先用 YAML 配置 + 简单 Java 类实现。例如自定义时间分片算法：
OpenJDK 24 Windows x64 官方参考实现（24+36），适合 Windows 环境进行 Java 开发、编译、运行和版本兼容性验证。
sharding-table-strategy:
standard:
sharding-column: create_time
sharding-algorithm-name: t_order_by_month
sharding-algorithms:
t_order_by_month:
type: CLASS_BASED
props:
strategy: STANDARD
algorithmClassName: com.example.OrderMonthShardingAlgorithm
这个类只需重写 doSharding 方法，用 SimpleDateFormat("yyyyMM") 解析时间并返回对应表名，清晰可控。
立即学习“Java免费学习笔记（深入）”；
