性能优化第一刀，该先砍「单次成本」还是先买「更多机器」？聊聊扩容与重构的排序

背景

做了 8 年性能优化，带过的团队里反复出现同一个争论：当 P99 开始劣化、业务方催得紧的时候，第一刀到底怎么砍？

我手上有个不太夸张但很典型的案例：某交易链路 P99 从 180ms 涨到 650ms，QPS 只涨了 40%。两种方案都摆在桌上——

• 方案 A（横向扩容）：副本从 6 加到 18，加钱、加配置、加发布窗口，4 小时上线。
• 方案 B（单次成本）：定位到一个 N+1 查询 + 一个未走索引的 join，改 SQL、补索引、加一层缓存，预计 2 周排期。

最后业务方选了 A，因为"先止血"。结果三个月后，同样的劣化在另一个接口又出现了，因为扩容只是把水位线抬高，没改变"单次请求要干 23 次 DB 往返"这个事实。

常见分歧

1. 扩容派：机器是最便宜的可回滚手段，改代码风险大、周期长，先扩容保命，优化慢慢来。
2. 重构派：扩容是"用预算买时间"，单次成本没降，规模一大账单会指数级涨，而且很多劣化（锁竞争、GC、连接池）扩容反而会放大。
3. 混合派：先扩容争取时间，但必须同步立项做根因，否则下季度还会再来一遍。

我的倾向

我倾向于一个更具体的判断标准：先算"单次成本"，再决定要不要扩容。

• 如果单次成本（CPU 时间、DB 往返、IO）已经稳定且接近理论下限，扩容是合理的。
• 如果单次成本里还有 30% 以上的"可优化空间"（N+1、慢查询、串行调用、可缓存未缓存），先做单次成本，扩容只是把劣化推迟。
• 判据我一般看三个数：单次请求的平均 CPU 时间、平均 DB 往返次数、平均 IO 字节数。这三个数没降之前，扩容基本是"花钱把火压小"。

但我也承认，这个判断在真实组织里很难落地——因为"算单次成本"本身需要 profiling 能力，而很多团队恰恰缺这个。

想听大家聊聊

1. 你所在团队，扩容 vs 优化的默认顺序是什么？有没有过"扩容后反而更慢"的坑？
2. 你们用什么指标来判断"单次成本还有多少可优化空间"？（我上面那三个数可能不全，欢迎补充）
3. 在业务方"今天就要上线"的压力下，你们怎么把"先做根因"这件事谈下来？或者有没有过谈不下来的妥协方案？
4. 有没有"扩容是唯一正确选择"的正面案例？什么特征下扩容反而是更优解？

抛出来就是想听听大家在线上的真实选择，不是要标准答案。