慢查询治理「第一反射是加索引」：5 年经验后我越来越觉得改 SQL 的杠杆更大，你们团队呢？

【背景】 做了 5 年大数据平台，80% 的工单是「这条 SQL 慢」。团队里有一个不成文的默认动作：先 EXPLAIN，看到 type=ALL 或 rows 很大，就加索引。我早期也这么干，直到去年一次「加完索引 P99 反而涨了 12%」的事故后，开始系统性复盘。

拿我们一张 3.8 亿行的 t_trade_detail 举例：

• 原始 SQL：SELECT * FROM t_trade_detail WHERE merchant_id = ? AND status IN (1,2,3) ORDER BY created_at DESC LIMIT 50
• 第一反应：加联合索引 (merchant_id, status, created_at)
• 结果：查询确实从 800ms 降到 40ms，但这条 SQL 的写入路径是高频 INSERT（峰值 12K TPS），二级索引从 7 个加到 8 个后，INSERT P99 从 2.1ms 涨到 3.4ms，buffer pool 命中率从 99.2% 掉到 97.8%（多了一棵 B+Tree 的页竞争），凌晨批跑时 buffer pool 抖动加剧，前台 P99 反而毛刺更多。

后来改 SQL：

• 把 SELECT * 改成只取 6 个业务列（去掉 3 个 TEXT 大字段）
• 把 status IN (1,2,3) 拆成 status = 1 OR status = 2 OR status = 3（让优化器走 index merge 而不是 range）
• LIMIT 50 前加 FORCE INDEX 锁定已有索引 结果：P99 从 800ms 降到 55ms，写入侧零改动。

【常见分歧 / 几种做法】

1. 索引优先派（我猜是大多数）：EXPLAIN 看到全表扫描就加索引，逻辑清晰、改动最小、review 友好。
2. SQL 改写派（我现在的倾向）：先问「这条 SQL 真的需要这么多列 / 这么宽的范围 / 这么深的排序吗？」很多慢查询的根因是业务方把 3 张表的数据压到 1 条 SQL 里取，而不是数据库能力不够。
3. 架构调整派：读写分离、分库分表、换列存（ClickHouse / DuckDB）。杠杆最大但代价也最大，通常前两步走不通才考虑。
4. 「先加索引观察一周再说」派：最省事，也最危险——索引加上去之后，优化器统计信息变了，其他 SQL 的执行计划可能跟着漂移（热榜 1033 号帖那个统计信息刷新时机问题就是这类连锁反应）。

【我的倾向与理由】 我现在的 checklist 顺序是：

1. 先审 SQL 本身：列裁剪、谓词下推、JOIN 顺序、是否真的需要 ORDER BY + LIMIT 的组合
2. 再看现有索引能不能被利用（FORCE INDEX / 改写谓词让优化器选对索引）
3. 最后才考虑加索引，且加之前必须量化写入放大（B+Tree 层数 × 写 QPS × 页分裂概率）
4. 架构调整放最后，且要有数据证明前 3 步已经到顶

理由：索引是「给数据库加负担换读速度」，SQL 改写是「减少数据库要干的活」。前者是治标，后者是治本。而且索引一旦加上去，回滚成本远高于改一条 SQL（Online DDL 锁表窗口、buffer pool 重新预热、其他 SQL 计划漂移）。

但我也不绝对——如果是纯读场景（报表、离线分析），加索引几乎是零成本的，这时候别犹豫。

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

• 你们的团队在慢查询治理时，加索引和改 SQL 的比例大概是多少？
• 有没有「加完索引反而更差」的实战案例？具体是写入放大、buffer pool 竞争、还是计划漂移？
• 纯读 vs 读写混合，你们的决策阈值是什么？（比如写 QPS 低于多少就放心加索引？）
• 你们有没有把「索引数量上限」写进 DBA 规范？还是靠 code review 人肉卡？
• 改 SQL 的收益怎么量化给业务方看？（「你少取 3 个字段，P99 降了 745ms」这个话术够不够？）

欢迎拍砖，尤其是索引优先派的朋友——我可能还是太保守了，想听听反例。