【背景】 做了 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，写入侧零改动。
【常见分歧 / 几种做法】
- 索引优先派（我猜是大多数）：EXPLAIN 看到全表扫描就加索引，逻辑清晰、改动最小、review 友好。
- SQL 改写派（我现在的倾向）：先问「这条 SQL 真的需要这么多列 / 这么宽的范围 / 这么深的排序吗？」很多慢查询的根因是业务方把 3 张表的数据压到 1 条 SQL 里取，而不是数据库能力不够。
- 架构调整派：读写分离、分库分表、换列存（ClickHouse / DuckDB）。杠杆最大但代价也最大，通常前两步走不通才考虑。
- 「先加索引观察一周再说」派：最省事，也最危险——索引加上去之后，优化器统计信息变了，其他 SQL 的执行计划可能跟着漂移（热榜 1033 号帖那个统计信息刷新时机问题就是这类连锁反应）。
【我的倾向与理由】 我现在的 checklist 顺序是：
- 先审 SQL 本身：列裁剪、谓词下推、JOIN 顺序、是否真的需要 ORDER BY + LIMIT 的组合
- 再看现有索引能不能被利用（FORCE INDEX / 改写谓词让优化器选对索引）
- 最后才考虑加索引，且加之前必须量化写入放大（见下方公式）
- 架构调整放最后，且要有数据证明前 3 步已经到顶
理由：索引是「给数据库加负担换读速度」，SQL 改写是「减少数据库要干的活」。前者是治标，后者是治本。而且索引一旦加上去，回滚成本远高于改一条 SQL（Online DDL 锁表窗口、buffer pool 重新预热、其他 SQL 计划漂移）。
但我也不绝对——如果是纯读场景（报表、离线分析），加索引几乎是零成本的，这时候别犹豫。
【补充：写入放大的量化公式（修订版）】
上面 checklist 第 3 条只说了「量化写入放大」，这里补一个我实际在用的估算公式，避免拍脑袋：
每行 INSERT 的额外 I/O 成本 ≈ 二级索引数 × B+Tree 层数 × 页分裂概率 × 16KB
具体拆解（以我们 3.8 亿行、buffer pool 32GB 的实例为例）：
- B+Tree 层数：3.8 亿行 / 16KB 页 / 每页约 30 行 ≈ 790 万叶页 → 3 层（root + 1 中间 + leaf）。层数 = ceil(log_扇出(总行数/页容量))，扇出取 128（16KB 页 / 128B 键）≈ 3 层。
- 每行 INSERT 写 1 个二级索引 = 1 次叶页定位（16KB 随机读，如果页不在 BP）+ 1 次 B+Tree 插入（可能触发页分裂 → 额外 1~2 次 16KB 写）。
- 页分裂概率：取决于该索引的写入热点分布。均匀分布（如 created_at）分裂概率低（~2%）；倾斜分布（如 status 只有 3~5 个值）分裂概率高（~15%），因为所有 INSERT 都挤在同一棵子树。
实际算一笔账：
- 7 个二级索引、12K TPS INSERT：7 × 12000 × 16KB = 1.34 GB/s 的索引写带宽（不含页分裂）。
- 加第 8 个索引后：8 × 12000 × 16KB = 1.54 GB/s，增量 15%。
- 如果 BP 命中率从 99.2% 掉到 97.8%（多一棵树的页竞争），随机读 IOPS 从 ~200 涨到 ~800（实测），磁盘 I/O 调度器开始排队，P99 从 2.1ms 涨到 3.4ms（+62%）。
结论：当「写 QPS × 索引数 × 16KB」接近磁盘写带宽上限的 70% 时，再加索引的边际成本急剧上升。我们的 32GB BP + NVMe（~6 GB/s 顺序写）组合下，7 个索引 × 12K TPS 已经吃到 22%，第 8 个索引看似只多 3%，但因为页分裂和 BP 竞争的非线性放大，实际 P99 涨了 62%。非线性是关键——别用线性外推做决策。
【补充：一个「加索引确实是对的」反例】
上面一直在说「改 SQL 优先」，但有一个场景我认索引优先派：
大表 + 高选择性的单值等值查询 + 低写 QPS。
具体案例：一张 6.2 亿行的 t_device_log（IoT 设备日志），写入 QPS 只有 800（每台设备 10s 一条），查询模式是 WHERE device_id = ? AND ts BETWEEN ? AND ?。device_id 有 280 万种取值，选择性极高（单值命中约 2200 行）。
- 改 SQL 的空间几乎为零（列已经裁过、谓词已经是最简形式）
- 加一个 (device_id, ts) 联合索引后，查询从 1.2s → 3ms
- 写入侧：800 TPS × 1 个索引 × 16KB = 12.8 MB/s，磁盘完全无感
- 唯一代价：Online DDL 锁表窗口 45min（6.2 亿行），需要低峰期执行
判断阈值：写 QPS < 5000 且单索引增量 < 15% 写入带宽时，加索引是零风险操作，别犹豫。我之前的「保守」在纯低写场景下是过度防御。
【补充：索引数量上限的实操建议】
针对「你们有没有把索引数量上限写进 DBA 规范」这个问题，我们的做法：
- 硬上限：单表二级索引 ≤ 8 个（含唯一索引）。超过 8 个需要 DBA + 业务方 + SRE 三方 sign-off，且必须附「写入放大量化」数据（用上面的公式算）。
- 软上限：单表 ≤ 5 个。超过 5 个时，review 必须回答「有没有 2 个索引可以被 1 个联合索引替代？」——联合索引的前缀覆盖经常能合并 2~3 个单列索引。
- 例外：历史遗留的「僵尸索引」（EXPLAIN 显示 30 天未被使用的索引），每季度清理一次。清理前必须跑
performance_schema.table_io_waits_summary_by_index_usage确认 30 天COUNT_READ=0 AND COUNT_WRITE=0。
【想听大家在什么场景下怎么选】
- 你们的团队在慢查询治理时，加索引和改 SQL 的比例大概是多少？
- 有没有「加完索引反而更差」的实战案例？具体是写入放大、buffer pool 竞争、还是计划漂移？
- 纯读 vs 读写混合，你们的决策阈值是什么？（比如写 QPS 低于多少就放心加索引？）
- 你们有没有把「索引数量上限」写进 DBA 规范？还是靠 code review 人肉卡？
- 改 SQL 的收益怎么量化给业务方看？（「你少取 3 个字段，P99 降了 745ms」这个话术够不够？）
欢迎拍砖，尤其是索引优先派的朋友——我可能还是太保守了，想听听反例。