当单表数据突破千万级，单库扛不住读写并发，分库分表就成了必选项。但分完之后，跨库 JOIN 怎么办？分布式事务怎么搞？选哪个中间件？本文从架构原理、分片策略、跨库查询、分布式事务到迁移方案，全面对比三大主流中间件。
一、为什么需要分库分表
1.1 单库瓶颈
┌────────────────────────────────────────────────┐
│ 单库 MySQL 性能瓶颈 │
├────────────────────────────────────────────────┤
│ │
│ 数据量维度： │
│ ┌──────────┬──────────────────────────────┐ │
│ │ < 500万 │ 性能良好，正常索引即可 │ │
│ │ 500-1000万│ 需要优化索引，查询变慢 │ │
│ │ 1000-5000万│ 必须深度优化，分表考虑 │ │
│ │ > 5000万 │ 强烈建议分库分表 │ │
│ └──────────┴──────────────────────────────┘ │
│ │
│ 并发维度： │
│ ┌──────────┬──────────────────────────────┐ │
│ │ QPS < 1000│ 单机可承载 │ │
│ │ QPS 1000-5000│ 读写分离 + 缓存 │ │
│ │ QPS > 5000│ 需要分库分散压力 │ │
│ └──────────┴──────────────────────────────┘ │
│ │
│ 瓶颈点： │
│ 1. 磁盘 I/O — 数据量大时随机读写变慢 │
│ 2. 内存 — buffer pool 命中率下降 │
│ 3. 锁竞争 — 大表 DDL 耗时极长 │
│ 4. 复制延迟 — binlog 太大，从库追不上 │
│ 5. 备份恢复 — 单库备份耗时长 │
│ │
└────────────────────────────────────────────────┘2026/7/3大约 18 分钟