【背景】
做了 8 年 DBA，最常被开发同学拿来"拍板"的一句话是："这个 SQL 慢，你加个索引不就完事了？"
我见过太多这样的链路：
- 一个订单列表接口，一次请求拆成 12 条子查询（N+1 的变体），单条 P50 只有 3ms，但串行叠加后 P99 飙到 180ms。开发说"加索引"，我加了，P99 降到 110ms。然后 QPS 涨了 3 倍，P99 又回去了。
- 一个报表接口，
SELECT ... FROM orders o JOIN order_items i JOIN products p ...三表 join 扫 200 万行。加联合索引后从 4.2s 降到 380ms，但 EXPLAIN 显示 filesort 还在，只是从 200 万行降到了 15 万行。下次数据量翻倍，问题原样回来。 - 一个库存扣减服务，每次扣减都要
SELECT FOR UPDATE再UPDATE，高峰期锁等待 P99 超过 800ms。加索引没用（锁等待不是扫描慢），最后改成UPDATE ... WHERE stock >= ?一条原子语句才解决。
这三个案例的共同点：根因在业务逻辑或表设计，不在索引缺失。加索引只是把"慢"的阈值往后推了 2~5 倍，没有消除慢的结构性原因。
【常见的几种做法 / 分歧】
我观察到的团队大致分三派：
派系 A：「索引优先，先止血再治本」
"线上 P99 已经 2s 了，你跟我讲架构？先加索引把 P99 压到 200ms 再说，根因下周再排。" 逻辑：线上不等人，索引是成本最低的止血手段（一条 DDL，秒级生效），改表结构 / 改业务代码是周级。 风险：如果"下周"一直不来（因为 P99 达标了，优先级降了），结构问题永远不被解决，数据量增长后反复出现。
派系 B：「索引是最后手段，先改设计」
"你的 SQL 写了 12 个子查询，这是 N+1 问题，跟索引没关系。你把 12 条合成 1 条 IN 查询，P99 直接降到 20ms，根本不需要加索引。" 逻辑：索引是写放大成本（每次 INSERT/UPDATE/DELETE 都要维护 B+ 树），加得越多写路径越慢。如果根因是查询写法，加索引等于"用写性能换读性能"，长期是亏的。 风险：改 SQL / 改表结构需要发版，周期长；而且"改 SQL"有时候比加索引更危险（语义变更、边界 case）。
派系 C：「看场景，没有银弹」
"看这个查询是读多写少还是读写均衡，看数据量是 10 万还是 10 亿，看 P99 是 50ms 还是 5s。不能一概而论。" 逻辑：没有统一的"先 A 后 B"规则，需要 case by case。 风险：如果团队没有统一的决策框架，每个 case 都要 DBA 和开发反复对齐，效率低。
【我的倾向与理由】
我倾向派系 C，但加一个硬约束：
加索引之前，必须回答两个问题：① 这个查询的根因是"扫太多行"还是"逻辑不对"？② 如果数据量涨 10 倍，这个索引还能撑住吗？
如果答案是"逻辑不对"（N+1、大表 join、缺聚合），那加索引是临时止血，必须在同一个 sprint 内排上根因修复，否则就是在技术债上加了一层"看起来好了"的贴纸。
如果答案是"扫太多行"（索引缺失或索引选择器不好），那加索引是正解，不需要改设计。
我的判断依据是 EXPLAIN 里的 rows 和 type：
type=ALL或type=range且rows > 10万：大概率是索引缺失，加索引是正解。type=ref或type=eq_ref但rows仍然很大（说明索引选择性不够）：需要看是不是查询逻辑有问题。type=const但 P99 仍然高：大概率是锁等待 / 网络 / 应用层问题，加索引没用。
【想听大家在什么场景下怎么选】
- 你团队有没有一个"慢查询治理 SOP"？ 比如 P99 > 200ms 必须走 DBA review，P99 > 2s 必须出根因分析？还是每次都是"谁慢谁加索引"？
- 加索引的"保质期"你们怎么管理？ 我见过一个团队，同一个表加了 14 个索引，后来 DBA 一查，有 5 个索引的命中率低于 0.1%（基本是"僵尸索引"），每次写操作都在白白维护它们。你们有没有定期清理僵尸索引的机制？
- "先止血再治本"的"本"谁来治、什么时候治？ 如果加索引把 P99 从 2s 压到 200ms，开发说"达标了，优先级降了"，根因修复永远排不上。你们怎么防止"止血变终态"？
- N+1 查询到底该在应用层修还是 DB 层修？ 比如 12 条子查询，是改成 1 条 IN + 应用层组装（改 Java 代码），还是 DB 层用 CTE / 物化视图？各自的取舍是什么？
欢迎分享你们团队的实战案例和踩坑经历，尤其是"加了索引之后又后悔"的故事。