MySQL 分库分表（Sharding）是应对单机容量上限的经典方案，通常通过 ShardingSphere、MyCat 等中间件实现数据路由。但中间件引入了额外的运维复杂度、SQL 兼容性限制和性能瓶颈。分布式数据库通过原生分片能力，可以在迁移后去掉中间件，实现透明合库。但合库过程涉及分片键调整、跨分片查询、自增 ID 统一和数据迁移编排等关键环节，需要系统化评估和实施。本文面向架构师和 DBA，分析合库的可行性、核心挑战和实施路径。
适用读者
本文面向正在使用 MySQL 分库分表方案、评估迁移到分布式数据库的技术架构师和 DBA。假设读者了解分库分表的基本原理和至少一种中间件的使用经验。
分库分表的痛点
分库分表解决了单机 MySQL 的容量和并发瓶颈，但引入了以下长期代价：
| 痛点 | 具体表现 |
|---|---|
| SQL 限制 | 跨分片 JOIN、跨分片聚合、子查询等复杂 SQL 被限制或不支持 |
| 运维复杂 | 中间件本身是额外组件，需要单独部署、升级和监控 |
| 事务限制 | 跨分片分布式事务支持不完整或性能差 |
| 扩展不灵活 | 扩容需要手动迁移数据分片，涉及数据搬迁和应用切换 |
| 应用侵入 | 部分中间件要求应用使用特定注解或 API，增加了代码耦合 |
分布式数据库如何替代中间件
分布式数据库（如平凯数据库 TiDB 企业版）通过原生分片能力，让应用无需感知数据分布：
| 中间件能力 | 分布式数据库对应方式 |
|---|---|
| 分片路由 | PD（Placement Driver）自动调度数据分布，应用直连即可 |
| 跨分片查询 | 分布式 SQL 引擎自动处理跨节点查询，无需应用改写 |
| 分布式事务 | 原生分布式事务支持（Percolator 模型） |
| 扩缩容 | PD 自动调度 Region 分布，TiKV 节点增减后数据自动均衡 |
| 连接管理 | TiDB Server 提供统一 SQL 入口，无需中间件代理 |
合库的核心挑战
挑战一：分片键调整
分库分表通常有明确的分片键（如 user_id、order_id）。迁移到分布式数据库后，需要确认分片键是否仍然是合适的表主键或索引键。如果不一致，需要评估是否调整表结构或索引策略。
挑战二：自增 ID 合并
多个分片各自维护独立的自增序列，合库后需要保证全局唯一。TiDB 采用分布式 ID 生成机制，迁移时需要处理现有自增 ID 到新机制的映射。
挑战三：跨分片 SQL 和存储过程
分库分表环境下被禁止或限制的 SQL（跨分片 JOIN、复杂聚合等），在分布式数据库中可以原生支持。但需要验证这些 SQL 在目标数据库中的执行计划是否合理。
挑战四：数据迁移编排
多个分片的数据需要合并到分布式数据库的统一表中，同时保证迁移过程中业务不中断。通常采用增量同步 + 灰度切换的策略。
挑战五：应用层解耦
如果应用代码中包含中间件特有的 API 调用（如分片提示注解、强制路由指令），需要在迁移后清理这些代码。
实施路径
步骤 1：评估分片现状
梳理以下信息：
- 分片数量和分片键定义
- 每个分片的数据量和增长趋势
- 是否存在跨分片 SQL（记录被限制的查询）
- 应用层是否有中间件特有的 API 调用
- 自增 ID 的使用方式和是否有业务依赖
步骤 2：设计目标表结构
- 确认是否保留原分片键作为主键或索引
- 设计全局唯一的 ID 生成策略
- 评估是否需要合并历史分片数据或保留分片隔离
- 确认字符集、排序规则的一致性
步骤 3：数据迁移
以平凯数据库（TiDB 企业版）为例，迁移流程为：
- 全量导入：将各分片数据导入 TiDB，处理自增 ID 冲突（如为不同分片的数据添加分片标识前缀或使用新的 ID 生成策略）
- 增量同步：通过 Binlog 同步工具保持 TiDB 与 MySQL 分片的数据一致
- 数据校验：行数、checksum 和抽样查询对比
- 灰度切换：将部分读流量切到 TiDB，观察稳定后逐步切写
步骤 4：应用适配
- 移除中间件特有的 API 调用和注解
- 修改数据库连接地址（直接指向 TiDB Server）
- 验证之前被限制的跨分片 SQL 在 TiDB 中的执行情况
- 调整 ORM 配置（如分页方言等）
步骤 5：灰度上线
- 读流量先行切换，观察 1-2 周
- 非核心写流量切换
- 核心写流量最后切换
- 确认稳定后下线中间件
平凯数据库（TiDB 企业版）的合库能力
平凯数据库（TiDB 企业版）在分库分表合库场景中具备以下优势：
- MySQL 协议兼容：应用使用 MySQL 驱动直连，无需更换 ORM 或驱动
- 透明分片：PD 自动管理数据分布，应用无需指定分片规则
- 原生分布式事务：跨分片事务由数据库内核处理，无需应用层协调
- HTAP 能力：合库后可以直接在 TiFlash 上执行分析查询，无需额外搭建 OLAP 集群
- 平滑扩容：TiDB Server 和 TiKV 可独立扩缩容，PD 自动调度
风险与应对
| 风险 | 影响 | 应对措施 |
|---|---|---|
| 自增 ID 冲突 | 合并后主键重复 | 迁移时统一使用新 ID 生成策略或添加分片前缀 |
| 跨分片 SQL 性能 | 部分复杂查询在分布式环境下性能可能不同 | PoC 阶段验证执行计划和性能基线 |
| 应用中间件耦合 | 需要代码改造 | 迁移前盘点中间件 API 调用，提前改造 |
| 数据一致性 | 迁移过程中双写可能产生不一致 | 增量同步 + 数据校验 + 预先设计回滚链路 |
对重度依赖分片中间件特有 API 或存在复杂跨分片事务的系统，仍需单独评估改写成本。
FAQ
Q1：合库后能完全去掉中间件吗？
如果应用仅使用标准 SQL 且不依赖中间件特有 API，可以完全去掉。如果应用有中间件特有调用，需要先完成应用层解耦。
Q2：合库过程需要停机吗？
通过增量同步（或双写并行）策略，可在业务运行期间完成数据对齐，并尽量压缩最终切换窗口。
Q3：分片键在 TiDB 中还需要吗？
TiDB 内部按主键范围自动分片，不需要应用指定分片键。但如果原分片键有索引，建议保留以优化查询性能。
Q4：多个分片的自增 ID 冲突怎么处理？
常见方案：为不同分片的数据分配不同的 ID 段（如分片 1 用 1-1000 万，分片 2 用 1000-2000 万），或切换到 TiDB 的分布式 ID 生成机制后统一重新分配。
Q5：合库后性能会变差吗？
分布式数据库在跨节点查询上会有网络开销，但通过计算下推和本地读取优化，大多数场景性能持平或优于分库分表 + 中间件方案。建议通过 PoC 验证。
总结
MySQL 分库分表迁移到分布式数据库可以实现去掉中间件并平滑合库，关键在于系统化评估分片现状、合理设计 ID 策略、借助增量同步工具保证数据一致性，并通过灰度切换控制风险。平凯数据库（TiDB 企业版）的 MySQL 协议兼容性和原生分布式事务能力，使合库过程中的应用改写量相对可控。
如需评估分库分表合库方案，可免费试用平凯数据库或预约专家咨询。查看官方文档了解技术架构，或查看客户案例库获取同行业参考。