慢查询治理到底在哪一层动刀：改 SQL、加索引、还是换架构？你们 80% 的精力花在哪一层？

【背景】

做了 5 年 DBA，慢查询治理是每周的固定动作。但每次性能评审，团队都会撞上同一个问题："这条 SQL 慢，我们到底该干嘛？"

答案从来不是唯一的——改 SQL 写法、加索引、拆表分库、加缓存、换引擎……每条路都有成本，每条路都有人觉得"应该先走我这条路"。

我们团队最近做了一次 12 个月慢查询治理复盘，统计了 200+ 条慢查询的"最终动刀位置"：

• 改 SQL 写法（补 WHERE、去 SELECT *、拆 JOIN、改子查询为 JOIN）：约 40%
• 加索引 / 调索引（新建、删冗余、调整列序）：约 35%
• 架构层（拆表、分库分表、加缓存、换引擎）：约 15%
• 其他（调 InnoDB 参数、调硬件、改业务逻辑）：约 10%

这个分布让我想发起一个讨论：你们团队的慢查询治理，精力到底花在哪一层？

【常见分歧 / 几种做法】

具体到某一条慢 SQL，团队里几乎每次都会出现三类分歧：

分歧一：改 SQL vs 加索引，谁先谁后？

• 业务开发倾向改 SQL："我补个 WHERE 条件就行了，不用动表结构、不用走 DDL 审批。"
• DBA 倾向加索引："你这条 SQL 每次全表扫 200 万行，补 WHERE 只是把扫描范围从 200 万缩到 50 万，本质还是全表扫；加索引才是治本。"
• 但加索引有真实代价：写放大、索引膨胀、即使 MySQL 8.0 的 Online DDL 在大表上也要几十分钟，期间 buffer pool 会被 DDL 的 change buffer 挤占，前台 P99 可能反而抖。

分歧二：优化单条 SQL vs 优化整个查询模式

• 有些慢查询是"一条 SQL 写得烂"，改 SQL 就行，成本最低。
• 有些是"查询模式本身有问题"：比如一个订单详情页一次请求发 7 条 DB 查询（N+1 变体），每条单独看都不慢，但加起来就慢了。改单条 SQL 只是止痛药，下次加一个字段又得重来。
• 这种"模式级"的问题，改 SQL 和加索引都解决不了，得改业务代码的调用方式——这就跨出了 DBA 的舒适区。

分歧三：谁来改？改完谁验证？

• DBA 改 SQL：看得懂执行计划、EXPLAIN ANALYZE、索引选择，但不懂业务语义，改完可能引入逻辑 bug（比如把 IN 改成 EXISTS 后 NULL 语义变了）。
• 业务开发改 SQL：懂业务语义，但可能不知道这条 SQL 走的是 index merge 还是 range scan，改了之后执行计划反而变差。
• 谁来改、谁来 review、谁来跑回归验证？这个分工在很多团队里是模糊的。

【我的倾向与理由】

我的经验是：先诊断、再排序、按成本从低到高动刀，具体分四步：

1. 看执行计划，确认瓶颈在哪。 EXPLAIN ANALYZE 看是索引没命中、回表太贵、排序/聚合太慢、还是锁等待。这一步 5 分钟，但能避免 80% 的"盲目加索引"。
2. 能用索引解决的，优先加索引——但有红线。 前提是确认索引不会让写性能恶化超过 5%（我们有这条红线），且表的数据量在索引维护成本可承受范围内。千万级以下的表，加索引基本是性价比最高的操作。
3. 索引解决不了的，改 SQL 写法。 这步需要 DBA 和业务开发一起看：DBA 看执行计划变化，业务看语义正确性。改完必须跑一遍核心用例回归。
4. SQL 写法也解决不了的，才考虑架构调整。 拆表、分库分表、加缓存、换引擎——这是成本最高的一步，需要评估迁移成本、回滚方案、业务影响窗口。不到万不得已不动。

但我不确定这个"成本从低到高"的顺序在所有场景下都成立。比如：

• 有些团队数据量已经到了亿级，加索引的 DDL 成本（时间 + 资源）可能比改 SQL 高一个量级；
• 有些场景下改 SQL 只是治标，数据量再涨一倍又得重来，不如一步到位改查询模式；
• 有些"慢查询"其实是锁等待导致的，改 SQL 和加索引都无效，得改事务粒度。

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

1. 你们的慢查询治理，80% 的精力花在哪一层？ 改 SQL、加索引、还是架构调整？有没有一个让你"花了 3 天改 SQL 最后发现加一个索引就行"的翻车案例？
2. 有没有遇到过"加索引反而让整体性能变差"的情况？ 写放大、索引膨胀、buffer pool 被挤占——你们怎么评估加索引的"副作用"？
3. 慢查询的"治理"到底是 DBA 的事还是业务开发的事？ 你们怎么分工？有没有一个"DBA 出诊断 + 业务出改动 + 双方共同验证"的协作流程？
4. 有没有一套可复用的"慢查询分级处理 SOP"？ 比如：P0 级（影响核心链路）→ 先 kill 再改；P1 级（影响非核心链路）→ 48 小时内出方案；P2 级（批量慢查询）→ 周会批量评审。想看看大家的分级标准。

欢迎拍砖，尤其是"我跟你做法不一样"的案例——这才是最有价值的。