【背景】 做了 5 年 DBA，我手上处理过最典型的场景：业务侧接口 P99 飙了，工单甩过来一句「慢查询，麻烦看看」。打开 explain，其实问题很清晰——一个 2000 万行的订单表，走了全表扫描，但加不加索引、谁来加、谁来改代码，团队内部往往要吵半小时到半天。
我自己踩过一个真实的坑：某次订单导出接口 P99 从 800ms 飙到 12s，业务方紧急工单。我这边分析下来，加一个联合索引 (tenant_id, created_at DESC) 能解决 90% 的情况，但这条 SQL 本身是 SELECT ... ORDER BY created_at LIMIT 20，开发同学坚持认为「索引是 DBA 的事，SQL 写法不用动」。我加了索引，上线后 P99 降到 180ms，看着挺好。结果两周后数据量涨到 4000 万行，P99 又回到 3s——因为 LIMIT 20 在深分页场景下，索引扫描的代价已经超过了全表扫描，优化器又开始选全表。最后还是开发改了 SQL，把深分页改成了游标分页，P99 稳定在 60ms。
【常见分歧】 我观察到团队里大概三种流派：
-
DBA 兜底派：慢查询一律 DBA 加索引解决，开发不改代码。好处是快，坏处是索引越加越多，最后索引数量到 15-20 个，写操作性能反而退化，而且数据量一变，执行计划又开始漂移。
-
开发自治派：DBA 只给分析建议，索引和 SQL 都归开发管。好处是责任清晰，坏处是开发往往没有 explain 的深度，「加个索引试试」成了万能药。
-
混合评审派：慢查询先开发自查 explain，DBA 给 30 分钟窗口 review，双方共同决定是加索引还是改 SQL 还是上缓存。好处是决策质量高，坏处是流程重，紧急工单等不起。
【我的倾向】 我倾向第三种，但有一个明确的「快慢通道」：
- 快通道（P99 > 3s 且影响线上）：DBA 先加索引止血，但必须在 24 小时内和开发一起复盘根因，确认是否需要改 SQL 或加缓存。索引只是止血带，不是治疗方案。
- 慢通道（P99 在 500ms-3s 之间）：走评审流程，DBA 给出三种方案（加索引 / 改 SQL / 加缓存）的成本收益对比，开发决策。
判断「该不该加索引」我用的一个简单标准：这个索引的写放大代价，和它带来的读收益，哪个更大？ 具体就是看这条 SQL 的 QPS 和表的写入 TPS。比如一条 QPS 只有 5 的查询，但表写入 TPS 是 2000，那加索引的写放大代价（每次 INSERT 都要维护这个 B+ 树）可能比读收益大得多，不如改 SQL 或者加缓存。
【想听大家聊的】
- 你们团队慢查询的「第一责任人」是谁？DBA 还是开发？
- 有没有遇到过「加了索引反而更慢」的案例？（比如索引导致写性能退化，或者优化器选错索引）
- 你们有没有一个量化的「该不该加索引」的判断标准，还是纯靠经验？
- 深分页场景，你们是怎么处理的？LIMIT/OFFSET、游标分页、还是直接禁止深分页？