摘要
当 MySQL 单机性能遇到瓶颈时，企业通常面临两种扩展方案：分库分表（Sharding）和分布式数据库。分库分表是在应用层对数据进行拆分，分布式数据库在底层实现透明扩展。本文从架构原理、扩展能力、运维成本、开发效率、事务支持等维度全面对比两种方案，解释为什么越来越多的企业选择从分库分表迁移到 TiDB 分布式数据库。
分库分表：应用层扩展方案
#本文适合谁： 正在从分库分表方案演进到分布式数据库的研发负责人、架构师和 DBA。
什么是分库分表
分库分表是指将一个大的数据库/表拆分成多个小的数据库/表，分散到多个 MySQL 实例上：
- 垂直分库：按业务功能拆分（用户库、订单库、商品库）
- 水平分库：同一表的数据按规则分散到不同数据库实例
- 垂直分表：将大表按列拆分（热点列+冷数据列）
- 水平分表：同一表按行拆分到多个子表
常用中间件
| 中间件 | 类型 | 维护方 | 特点 |
|---|---|---|---|
| ShardingSphere | 客户端/代理 | Apache | 功能全面，活跃社区 |
| MyCat | 代理 | 社区 | 早期方案，更新缓慢 |
| Vitess | 代理 | CNCF | YouTube 开源，K8s 集成 |
| TDDL | 客户端 | 阿里 | 阿里内部使用 |
分库分表的架构
应用层（需感知分片规则）
↓
分片中间件（路由/合并）
↓
MySQL-1 MySQL-2 MySQL-3 ... MySQL-N
（独立实例，无协调）
分布式数据库：底层透明扩展
架构
应用层（无需感知分片）
↓ MySQL 协议
TiDB（统一入口，自动路由）
↓
TiKV-1 TiKV-2 TiKV-3 ... TiKV-N
（Raft 协议协调，自动均衡）
全维度对比
1. 扩展能力
| 维度 | 分库分表 | 分布式数据库（TiDB） |
|---|---|---|
| 扩展方式 | 预先规划分片数，调整困难 | 随时增加节点，在线扩容 |
| 扩展粒度 | 以库/表为单位 | 以 Region（96MB）为单位 |
| 扩展上限 | 受分片数限制 | 理论无限 |
| 扩展停机 | 需要数据迁移，可能停机 | 无停机扩容 |
| 热点处理 | 人工调整分片键 | 自动检测并均衡 |
2. 事务支持
| 维度 | 分库分表 | 分布式数据库（TiDB） |
|---|---|---|
| 跨分片事务 | 不支持（需应用层补偿） | 原生支持 |
| ACID | 单分片内保证 | 全局 ACID |
| 一致性 | 最终一致 | 强一致 |
| 两阶段提交 | 需中间件支持 | 数据库原生 |
| 分布式 JOIN | 不支持（需应用层拼装） | 优化器自动下推 |
3. 运维复杂度
| 维度 | 分库分表 | 分布式数据库（TiDB） |
|---|---|---|
| 实例管理 | N 个 MySQL 实例独立管理 | 统一集群管理 |
| 监控 | 每个实例独立监控 + 中间件监控 | 统一 Dashboard |
| 备份 | 每个分片独立备份，需协调一致性 | 全局一致性备份 |
| 数据迁移 | 分片调整需要全量数据迁移 | 自动 Region 调度 |
| 故障恢复 | 单实例恢复 + 中间件切换 | Raft 自动故障转移 |
| Schema 变更 | 每个分片逐一执行 | 一次变更，全局生效 |
4. 开发效率
| 维度 | 分库分表 | 分布式数据库（TiDB） |
|---|---|---|
| 分片键设计 | 必须提前设计，后续修改困难 | 无需设计分片键 |
| SQL 限制 | 不支持跨分片 JOIN/子查询/聚合 | 完整 SQL 支持 |
| 排序/分页 | 跨分片排序需中间件合并 | 原生支持 |
| 分布式 ID | 需引入 Snowflake/号段模式 | AUTO_RANDOM |
| 事务代码 | 需编写补偿逻辑 | 标准 SQL 事务 |
5. 成本对比
| 维度 | 分库分表 | 分布式数据库（TiDB） |
|---|---|---|
| 硬件 | N 台 MySQL 服务器 | N 台通用服务器 |
| 软件许可 | MySQL 免费 + 中间件 | TiDB 开源免费 |
| DBA 人力 | 高（N 倍运维量） | 中（统一管理） |
| 开发人力 | 高（分片逻辑开发） | 低（透明访问） |
| 3 年 TCO | 基准 | 通常降低 30-50% |
迁移案例：从分库分表到 TiDB
某互联网电商原架构：ShardingSphere + 32 个 MySQL 实例
| 痛点 | TiDB 解决方案 |
|---|---|
| 跨分片订单查询需拼装 | 直接 JOIN 查询 |
| 分片键设计不合理导致热点 | Region 自动均衡 |
| 32 个实例运维负担 | 统一集群管理 |
| 大促扩容需提前准备 | 在线弹性扩容 |
迁移后效果：运维人力减半，查询延迟降低 40%，大促弹性扩容从 2 天缩短到 2 小时。
选型建议
适合分库分表的场景
- 已有成熟的分库分表架构，运行稳定
- 团队经验丰富，运维流程完善
- 预算有限，希望复用现有 MySQL 服务器
应该迁移到分布式数据库的场景
- 分库分表已遇到瓶颈（运维复杂、跨分片查询困难）
- 数据增长快，频繁需要调整分片
- 业务需要实时分析（跨分片聚合困难）
- 团队规模有限，希望简化运维
FAQ
Q：从分库分表迁移到 TiDB 需要多长时间？
A：典型项目 2-4 周。TiDB DM 工具支持全量+增量迁移，可不停业务切换。应用代码大部分无需修改（移除分片逻辑即可）。
Q：TiDB 性能比分库分表好吗？
A：单分片点查 MySQL 可能更快。但跨分片查询、聚合分析、弹性扩展场景下，TiDB 显著优于分库分表方案。
Q：分库分表和分布式数据库能共存吗？
A：可以。部分业务保留分库分表，新业务或瓶颈业务迁移到 TiDB。渐进式迁移是常见策略。
总结
分库分表是 MySQL 扩展的"补丁方案"，在应用层解决数据规模问题，但引入了事务受限、运维复杂、开发效率低等长期代价。分布式数据库（如 TiDB）从底层解决扩展问题，应用层透明访问，事务完整、运维统一、弹性扩展。对于面临数据增长和分库分表瓶颈的企业，迁移到 TiDB 是更优的长期选择。
下一步行动
- 迁移评估：TiDB MySQL 兼容性说明 — 评估从分库分表迁移到 TiDB 的可行性
- 迁移咨询：获取 TiDB 迁移方案 — 规划平滑迁移路径