慢查询治理的分歧：「先改 SQL 再谈索引」和「索引能解就建索引」，你的团队到底走哪条？

【背景】 我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建索引本身成了事故」的场景。

先给一个具体的数：我们库里一张 4.2 亿行的表，加一个普通二级索引的 Online DDL（gh-ost 走影子表）跑了 11 小时，期间业务写入放大约 1.4 倍，影子表空间临时多吃 180GB。加索引这件事，在小表上是 30 秒的热操作，在大表上是一次需要排期、需要备份、需要回滚预案的「变更事件」——但大多数团队在决策时，把它当成了和改一行 WHERE 子句同级的小事。

【常见的几种分歧】 我见过三种典型路线，各有各的拥趸：

1. 「索引优先派」：EXPLAIN 出来 filesort / type=ALL，能加索引解决的绝不改代码。理由是 SQL 改写侵入业务、回归成本高，而索引是「无侵入」的。
2. 「改写优先派」：先问「这条 SQL 为什么长这样」，能不能把 OR 拆成 UNION、把函数索引问题改成预计算列、把 N+1 拍平。理由是「索引是给写得差的 SQL 擦屁股，擦一次算一次，债还在」。
3. 「架构兜底派」：单条 SQL 治理到极限后，直接读副本分流 / 缓存 / 数仓下沉，慢查询本身被「绕过去」。

三条路线单看都对，分歧在于优先级排序和谁来拍板——是 DBA 一票否决，还是业务团队自己权衡，还是有个量化的判据（比如：表行数 > X 则索引变更自动升级到变更评审；或改写预估回归成本 > N 人日则优先索引）。

【我的倾向与理由】 我倾向「改写优先，但带两条硬约束」：

• 约束一：索引不是免费的，它的成本是持续性的（每次写入都要维护，B+ 树变高、buffer pool 命中率下降、空间占用），而 SQL 改写的成本是一次性的（回归测试、上线风险）。所以默认应该先摊一次性成本，再考虑持续性成本。
• 约束二：改写必须有明确的「不可改写」清单——涉及跨表语义等价性无法证明的（比如隐式类型转换、驱动改写后执行计划漂移）、以及业务方无法回归的场景（历史遗留的报表 SQL，调用方是 ETL 脚本，改一行没人敢验），这两类直接走索引或架构兜底，不恋战。

换句话说，我把决策从「谁的意见对」变成「成本性质不同，默认先花一次性的钱」，这样至少团队吵起来时有个锚点。

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

1. 你的团队慢 SQL 治理有没有成文的优先级判据？还是每次靠 DBA 和业务各退一步？
2. 大表（>1 亿行）加索引，你们有没有过「索引上线了，写入 P99 反而涨了」的翻车记录？怎么发现的、怎么回的？
3. 「SQL 改写」在你们团队算业务侧的活还是 DBA 的活？有没有出现过「DBA 提了改写方案，业务说回归不起，最后还是加了索引」的拉扯？
4. 有没有人做过量化的对比：同一批慢 SQL，改写 vs 索引，各自的 P99 收益、写入放大、回归成本，方便贴个数字吗？