现象或背景
我在一个 5 亿行级的订单库上做过两年慢查询治理，最深的一条体感是：80% 的慢 SQL 最后都靠索引收敛了，但真正让我睡不着的，恰恰是那 20%「建了索引也解决不了、或者建了索引本身成了事故」的场景。
先给一个具体的数：我们库里一张 4.2 亿行的表，加一个普通二级索引的 Online DDL（gh-ost 走影子表）跑了 11 小时，期间业务写入放大约 1.4 倍，影子表空间临时多吃 180GB。加索引这件事，在小表上是 30 秒的热操作，在大表上是一次需要排期、需要备份、需要回滚预案的「变更事件」——但大多数团队在决策时，把它当成了和改一行 WHERE 子句同级的小事。
原理或根因分析
我见过三种典型路线，各有各的拥趸：
- 「索引优先派」：EXPLAIN 出来 filesort / type=ALL，能加索引解决的绝不改代码。理由是 SQL 改写侵入业务、回归成本高，而索引是「无侵入」的。
- 「改写优先派」：先问「这条 SQL 为什么长这样」，能不能把 OR 拆成 UNION、把函数索引问题改成预计算列、把 N+1 拍平。理由是「索引是给写得差的 SQL 擦屁股，擦一次算一次，债还在」。
- 「架构兜底派」：单条 SQL 治理到极限后，直接读副本分流 / 缓存 / 数仓下沉，慢查询本身被「绕过去」。
三条路线单看都对，分歧在于优先级排序和谁来拍板——是 DBA 一票否决，还是业务团队自己权衡，还是有个量化的判据（比如：表行数 > X 则索引变更自动升级到变更评审；或改写预估回归成本 > N 人日则优先索引）。
具体做法
我倾向「改写优先，但带两条硬约束」：
- 约束一：索引不是免费的，它的成本是持续性的（每次写入都要维护，B+ 树变高、buffer pool 命中率下降、空间占用），而 SQL 改写的成本是一次性的（回归测试、上线风险）。所以默认应该先摊一次性成本，再考虑持续性成本。
- 约束二：改写必须有明确的「不可改写」清单——涉及跨表语义等价性无法证明的（比如隐式类型转换、驱动改写后执行计划漂移）、以及业务方无法回归的场景（历史遗留的报表 SQL，调用方是 ETL 脚本，改一行没人敢验），这两类直接走索引或架构兜底，不恋战。
换句话说，我把决策从「谁的意见对」变成「成本性质不同，默认先花一次性的钱」，这样至少团队吵起来时有个锚点。
踩过的坑或反直觉之处
【补一个我提的 Q2 的翻车数据（之前漏了）】 有一张 2.8 亿行的库存流水表，我们加了第 6 个二级索引（之前 5 个），上线当天读 P99 从 45ms 降到 8ms，看起来很完美。但第 3 天，写入 P99 从 12ms 涨到 34ms，INSERT QPS 稳定但 buffer pool 命中率从 99.2% 掉到 97.1%——根因是 6 个二级索引让每次 INSERT 要额外维护 1 棵 B+ 树的 3~4 层节点，在 buffer pool 8GB 的约束下，索引页把热数据页挤出去了。回滚索引后写入 P99 当天恢复到 13ms。
教训：加索引的写入代价不是「上线那一刻」体现的，而是「buffer pool 被索引页占满后的第 2~3 天」才暴露——因为 InnoDB 的 LRU 驱逐是渐变的。所以索引变更的监控窗口至少给 72 小时，别只看上线当天的 P99。
【补一个 gh-ost 在 MySQL 8.0 上的坑（之前没提）】
gh-ost 的 --chunk-size 默认 1000 行，在 8.0 的行格式 DYNAMIC + 大字段（TEXT/JSON > 1KB off-page）场景下，每个 chunk 的 SELECT ... FOR UPDATE 实际锁住的行数远大于 1000（因为 off-page 的 BLOB 指针在聚簇索引里，但实际数据在独立的 extent 页上，gh-ost 的 row_id BETWEEN 切分假设不成立）。我们一次 4.2 亿行的表加索引，chunk-size 调到 200 才把 lock_wait 从平均 320ms 压到 15ms 以下。
结论与可复用清单
- 优先级排序：默认优先 SQL 改写（一次性成本），再考虑索引（持续性成本），最后才是架构兜底（无侵入但代价高）。
- 量化判据：表行数 > X 则索引变更自动升级到变更评审；或改写预估回归成本 > N 人日则优先索引。
- 不可改写清单：涉及跨表语义等价性无法证明的（比如隐式类型转换、驱动改写后执行计划漂移）、以及业务方无法回归的场景（历史遗留的报表 SQL，调用方是 ETL 脚本，改一行没人敢验），这两类直接走索引或架构兜底。
- 监控窗口：索引变更的监控窗口至少给 72 小时，别只看上线当天的 P99。
- gh-ost 配置：在 MySQL 8.0 的 DYNAMIC 行格式 + 大字段场景下，
--chunk-size调到 200 才能显著降低lock_wait。 - 索引变更留痕：把每条索引变更也当「发布事件」：在元数据里记 index_name / 列序 / 选择性快照 / 责任人 / 删除原因。
- 写放大系数：高频写入表的索引变更必须附 INSERT/UPDATE 吞吐压测数据，否则只优化了读、悄悄拖垮了写。
【想听大家在什么场景下怎么选】
- 你的团队慢 SQL 治理有没有成文的优先级判据？还是每次靠 DBA 和业务各退一步？
- 大表（>1 亿行）加索引，你们有没有过「索引上线了，写入 P99 反而涨了」的翻车记录？怎么发现的、怎么回的？（我上面补了一个 6 索引 + buffer pool 驱逐的 case）
- 「SQL 改写」在你们团队算业务侧的活还是 DBA 的活？有没有出现过「DBA 提了改写方案，业务说回归不起，最后还是加了索引」的拉扯？
- 有没有人做过量化的对比：同一批慢 SQL，改写 vs 索引，各自的 P99 收益、写入放大、回归成本，方便贴个数字吗？