分库分表核心是逻辑表到物理库表的可维护映射，推荐分库（用户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 不自动建表，否则插入报错。

js2java

JavaScript 到 Java 全栈翻译助手，专为前端开发者学习 Java 或快速实现后端业务逻辑而设计。当用户提到以下场景时必须使用此技能： - "帮我把这段 JS 代码转成 Java" - "用 Java 怎么写这个逻辑" - "我习惯用 JS 写，想翻译成 Java" - "教我 Java，我要写后端接...

下载

配置落地要点：YAML + 自定义算法够用不臃肿

不用硬编码分片逻辑，优先用 YAML 配置 + 简单 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免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南