分库分表实战：ShardingSphere 与中间件方案的取舍

结论：分库分表不是架构升级的起点而是终点，90% 的"需要分片"其实是索引、慢查询和冷热数据没治理好；真到了必须分片那一步，Java 单一技术栈优先选 ShardingSphere-JDBC（客户端分片），多语言/多团队/需要统一治理时选 ShardingSphere-Proxy 或 MyCat、DBLE 这类代理中间件，自研分片层只在极端体量下有回报。

先确认：你到底是不是真的需要分库分表

结论：单表行数从来不是分片的充分理由，查询模式和写入瓶颈才是。

常见的"经验阈值"是单表 2000 万行、单库 500GB 开始考虑，但这只是提醒你去做压测，不是命令你立刻分片。真正该动手的信号有三个：单表数据量导致 B+ 树层高上升、DDL 和备份窗口不可接受；写入 QPS 打满单库 IO；单库连接数或磁盘容量触顶。

在分片之前，按顺序试这几件事：加合适索引、消灭全表扫描与大分页、读写分离、把历史数据归档到冷库（大部分业务 90 天前的数据访问率低于 1%）、用 MySQL 原生分区表过渡。这些手段能拖住一到两年，而分片引入的复杂度是永久性的——跨片 JOIN、分布式事务、全局 ID、扩容，一个都躲不掉。

客户端分片 vs 代理分片：本质是「性能」与「治理」的取舍

结论：ShardingSphere-JDBC 把分片逻辑放在应用进程内，性能损耗最小但治理分散；ShardingSphere-Proxy 把它放在独立进程，运维统一但多一跳网络与自身可用性成本。

ShardingSphere-JDBC 以 jar 包形式接入，本质是一个增强的 JDBC 驱动，SQL 改写、路由、归并都在应用内存里完成，额外延迟通常在微秒级，不增加网络跳数，也不引入新的故障节点。代价是：每个应用都要引依赖、升级版本要全量重启、连接数随实例数线性放大，DBA 无法在应用之外统一改规则。

ShardingSphere-Proxy 是一个独立部署的服务，对应用伪装成 MySQL，支持任意语言客户端。好处是配置集中、改规则不用动业务、能跨语言复用、可以做统一的 SQL 审计与限流。代价是每次查询多一跳网络、Proxy 本身要集群和负载均衡、SQL 兼容性需要逐条验证——复杂子查询、窗口函数、存储过程经常是踩坑重灾区。

选择口径很直接：如果你全部是 Java 应用、团队有能力管理依赖版本，选 JDBC；如果技术栈里有 Go、Python、PHP，或者你希望 DBA 能接管分片规则，选 Proxy。ShardingSphere 5.x 之后两种形态共用同一套逻辑配置，前期选错也可以迁移，成本可控。

分片设计才是决定生死的部分

结论：分片键一旦选错，后面所有优化都是在补救错误的分片。

选分片键遵守三条：高基数、分布均匀、高频查询条件必带。用户中心用 user_id，订单用 buyer_id，交易流水可用 order_id。反面教材是用 status、create_time 这类低基数或范围倾斜字段做分片键，会立刻产生热点分片。

几个必须提前设计的点：

• 分片数：单库分片数取 2 的幂（如 16、32），便于后续翻倍扩容时按位运算迁移，避免全量重分布。
• 绑定表：把有父子关系、JOIN 频繁的表（订单与订单明细）用同一分片算法，路由到同一分片，避免跨库 JOIN 变成笛卡尔积。
• 广播表：字典、配置类小表设为广播表，每库一份，规避跨片关联。
• 全局唯一 ID：别用数据库自增。雪花算法要处理时钟回拨和 workerId 分配，号段模式（Leaf-segment）更稳但依赖发号服务。
• 分页：`LIMIT 10000, 20` 在分片场景下会把 10000+20 条记录拉到内存归并，性能灾难。用分片键带上游标翻页，或限制最大页深。
• 分布式事务：优先做「单分片本地事务 + 跨片最终一致」，Seata AT 模式能兜底但会锁行、有性能损耗，别把强一致当默认选项。

迁移与扩容的落地步骤

结论：分片上线必须走「双写—迁移—校验—灰度切读—切写」五步，直接停机切库的时代已经过去了。

具体做法：① 新建分片集群，应用开启双写（老库为主、新库异步写）；② 用 binlog 或批任务做全量数据迁移，迁移工具选 DataX、Canal 或 DTS 均可；③ 做数据校验，全量 checksum 比对加抽样行级比对，差异必须归零再往下走；④ 灰度切读，先切 1% 只读流量观察路由正确性与耗时；⑤ 切写，老库保留只读一段时间作回滚兜底，观察 1-2 周后下线。

扩容时优先用双写迁移而不是一致性哈希自动再平衡——前者可控、可回滚、可校验，后者在线上往往演变成不可预测的数据风暴。

收束一下：先用治理手段验证是否真需要分片；确定要分，就在客户端与代理之间按技术栈和治理诉求二选一；然后把 80% 的精力砸在分片键、绑定表、全局 ID 和迁移方案上。中间件只是工具，决定系统能不能扛住的是数据分布设计。