单表从 1 亿行到 10 亿行：升配、读写分离、分区、分库分表，你的优先级到底怎么排

背景

做了 10 年 DBA，被业务方问得最多的一个问题就是："我们的表要爆了，下一步该怎么办？"

每次问这话的时候，团队里通常已经开始在四条路线之间摇摆：

1. 垂直扩容：升配，更大规格的实例（vCPU / 内存 / SSD 升级一档），最便宜、最快、零代码改动，但天花板清晰可见——单实例到一定规格后性价比断崖式下跌，且解决不了"逻辑分片"问题；
2. 读写分离：主从架构 + 只读流量打从库，对读多写少场景几乎是无脑收益，但对"写后即读"是定时炸弹（社区里已经有人写过主从延迟 4.7 秒读串的 P0，我深有同感）；
3. 分区表：RANGE / LIST / HASH 在单实例内做物理切分，对"按时间清理历史数据"和"按业务维度查询"友好，但跨分区聚合、跨分区事务、跨分区 Join 都是坑，且分区不是水平扩展——单实例瓶颈该有还是有；
4. 分库分表：真正的水位线方案，能水平扩展，但代价是跨库事务、全局 ID、跨库 Join、运维复杂度，都是要还的债。

我注意到社区里已经有人讨论过「千万级大表该不该上分区表」，那个帖子聚焦在"分区 vs 不分区"的二元选择；这次我想聊的更往前一步：当数据量、QPS、P99 三个信号同时开始劣化时，四条路线的引入顺序和退出条件，到底应该长什么样。

常见分歧

我见过至少三种典型流派：

• 保守派：能升配就升配，能加只读就加只读，分区表是"万不得已"，分库分表是"最后手段"。优点是稳，缺点是往往在"万不得已"已经变成"必须"的时候才动手，窗口极短；
• 激进派：数据量到一定阈值（比如单表 5000 万行）直接上分库分表，"早拆早省心"。优点是架构干净，缺点是中小团队根本消化不了跨库事务和全局 ID 的复杂度，拆完发现 80% 的查询根本不需要分片；
• 场景派：看读写比、看查询模式、看清理策略，每个场景给不同答案——我个人最认同这一派，但团队里很难统一，因为"场景"本身就需要先摸清楚，而业务方往往只告诉你"表要爆了"。

我的倾向与理由

我自己的判断框架是"先摸瓶颈，再定路线"，具体顺序大致是：

1. 第一刀永远是定位：慢查询 EXPLAIN、索引命中率、buffer pool 命中率、连接池水位、磁盘 IO 曲线，全部拉出来看 7 天。这一步能排除 60% 的"假扩容"——很多时候表没爆，是某条 SQL 在某个高峰被某个新业务打爆了；
2. 第二刀看瓶颈类型：
   • CPU / IO 瓶颈 → 升配（最便宜）；
   • 读 QPS 高、写 QPS 低、且业务能容忍秒级延迟 → 读写分离（要配"写后即读"兜底，比如强制走主或读己之写一致性）；
   • 数据量大但单行查询为主、按时间清理 → 分区表（RANGE 按时间）；
   • 单实例已经到规格上限、且查询模式允许水平分片 → 分库分表（要配全局 ID 和跨库事务方案，或者干脆接受"不支持跨库事务"）。
3. 第三刀是退出条件：每条路线都要写清楚"什么信号出现就退出"——升配退出条件是"升完还在 P99 红线"；读写分离退出条件是"主从延迟 P99 > 1s 或一致性投诉"；分区表退出条件是"跨分区聚合占比 > 30%"；分库分表退出条件是"跨库事务占比 > 50%"。没有退出条件的扩容，就是债务。

想听大家在什么场景下怎么选

特别想收集几类案例：

1. 你们团队单表数据量到多少行 / 多大 GB 的时候，开始认真考虑扩容？这个阈值是怎么定的（拍脑袋还是压测出来的）？
2. 你们有没有"升配 / 读写分离 / 分区 / 分库分表"实际走过的路线？事后最庆幸和后最悔的决策分别是什么？
3. 读写分离 + "写后即读"你们是怎么兜底的？强制走主、读己之写一致性、还是干脆不分离？
4. 跨库事务你们是怎么处理的？2PC、TCC、还是"业务上根本不支持跨库事务"？
5. 你们团队有没有一套可复用的"扩容决策 checklist"？如果有的话，最关键的 3 条是什么？

我会在帖子里持续补充自己的案例（包括一次"升配到顶还是没救"和一次"分库分表拆完发现 70% 查询没受益"的复盘），也欢迎大家带着具体数据来聊——空对空的架构讨论我最怕了。