06 - 为什么要分库分表

前面所有招（索引、SQL、缓存、读写分离、分区表）都用尽了，数据库还是扛不住——这时才轮到分库分表。这一章讲清楚：它到底解决什么问题、分库和分表分别针对什么。

一句话先记住：分库分表 = 把一个「装不下、扛不住」的大库大表，拆成多个小库小表，分散到多台机器上。

6.1 单库单表会遇到什么天花板

一张表、一个库，无论怎么优化，都有物理上限：

① 单表数据量太大
   一张表几亿、几十亿行，即使有索引，B+ 树层数变高、维护变慢，
   备份、加字段（DDL）都可能要几小时甚至锁表

② 单库容量/连接数到顶
   一台机器磁盘就那么大、CPU/内存就那么多、
   数据库能开的连接数有上限

③ 单机写入能力到顶
   读可以靠从库分摊，但所有写都压在主库一台机器上
   → 写 QPS 到达单机极限，再也上不去（读写分离救不了写）

关键信号：当你发现瓶颈是「单台机器的物理极限」——磁盘装不下、单机写不动了——这才是分库分表的场景。如果只是「查询慢」，回去看索引和 SQL。

6.2 分库 vs 分表：解决不同的问题

「分库分表」其实是两个动作，解决的问题不一样：

分表（Sharding Table）：把一张大表拆成多张小表
  目标：解决「单表数据量太大」
  例：user 表 5 亿行 → 拆成 user_0 ~ user_15 共 16 张表，每张约 3000 万行

分库（Sharding Database）：把数据拆到多个数据库/多台机器
  目标：解决「单机容量、连接数、读写能力到顶」
  例：一个库扛不住 → 拆成 db_0 ~ db_3 共 4 个库，分布在 4 台机器

6.3 两个维度的组合

分库和分表可以组合，形成四种情况：

                单表              分表（多表）
        ┌──────────────────┬──────────────────┐
 单库    │  ① 最初的样子       │  ② 分表不分库       │
        │  一库一表          │  一个库里多张小表    │
        │                  │  (缓解单表大)       │
        ├──────────────────┼──────────────────┤
 分库    │  ③ 分库不分表       │  ④ 分库又分表       │
（多库） │  多个库各一张表      │  多个库，每库多张表  │
        │  (缓解单机压力)      │  (最彻底，扛最大量)  │
        └──────────────────┴──────────────────┘

• ② 分表不分库：数据量大但单机还扛得住 → 常常用「分区表」就能替代（见第 05 章）
• ④ 分库又分表：超大规模系统的终极形态，也最复杂

6.4 分库分表带来的「甜蜜」与「代价」

甜蜜（解决了什么）

· 单表变小 → 查询、索引、DDL 都快了
· 数据分散多机 → 突破单机容量、连接数、读写能力上限
· 可以水平扩展 → 不够就再加机器加分片

代价（引入了什么新问题，下一章详谈）

· 主键怎么办？   → 多个表/库，自增 ID 会冲突（要分布式 ID）
· 查询怎么办？   → 跨库 JOIN 做不了、跨库分页很麻烦
· 事务怎么办？   → 一个操作涉及多个库 → 分布式事务，极其头疼
· 扩容怎么办？   → 分片数不够了要加，数据迁移很痛苦
· 运维怎么办？   → 从管一个库变成管一堆库，复杂度飙升

一句话认清本质：分库分表是用「架构和运维的巨大复杂度」换「突破单机物理上限」。收益很实在，代价也很沉重。

6.5 什么时候才真该分库分表

✅ 该考虑（同时满足）：
   · 前面所有优化（索引/SQL/缓存/读写分离/分区表）都做了，仍扛不住
   · 瓶颈明确是「单机物理极限」（磁盘、写 QPS、连接数）
   · 数据量还在持续高速增长，看得到天花板

❌ 别急着上：
   · 只是查询慢 → 先优化索引和 SQL
   · 只是读压力大 → 先加缓存 + 读写分离
   · 单表大但单机够用 → 先用分区表
   · 数据量其实没那么大（几百万行谈不上分库分表）

忠告：分库分表是很多团队「过早优化」的重灾区。不要为了显得高级而分库分表——它带来的复杂度，可能让小团队得不偿失。

本章小结

下一章预告：确定要分了，那到底「怎么拆」？垂直拆、水平拆、分片键怎么选？这是分库分表最核心的决策。

上一章 ← 05 - 读写分离与缓存 ｜ 下一章 → 07 - 怎么分：拆分策略