慢查询治理该背 KPI 吗：「消灭 80% 慢查询」和「P99 改善 5ms」哪个更该写进季度目标？

【背景】

做了 8 年 DBA，每年给业务方交"慢查询治理报告"时最纠结的不是技术，而是怎么定义"治理完成了"。

去年我们团队定了两条线：

• 线 A：月均慢查询（>200ms）从 3200 条降到 800 条以下 → 达成，OKR 打勾
• 线 B：核心 5 个 OLTP 接口 P99 从 180ms 降到 120ms → 只完成 60%

复盘发现：80% 精力花在消灭"高频但影响 P99 不大"的后台报表 SQL（T+1 对账 job、数据导出），真正影响用户体感的 OLTP 路径反而没动。指标达标了，用户没感觉。

【几种常见做法】

1. 按慢查询条数考核：DBA 好量化、好汇报，但极易变成"刷指标"——把阈值从 200ms 调到 500ms 就"达标"了，或者把后台 job 的 SQL 拆成 10 个短查询来"消灭慢查询"，实际 I/O 总量没变。
2. 按业务 P99 改善考核：用户体感好，但 DBA 背了不属于自己的指标（JVM GC、网络抖动、应用层序列化都影响 P99），而且 P99 改善归因到"那条索引"很难自证。
3. 按"业务方满意度"考核：最软，完全无法量化，年底靠 PPT 汇报。

【我的倾向与理由】

我倾向分层背指标，把"我能控制的"和"我影响的"分开：

• DBA 自己背（可控）：慢查询 Top N 的"消除周期"——从慢日志发现到索引/SQL 修复上线的天数。中位数 ≤3 天，P90 ≤7 天。这是纯执行效率，不依赖业务方配合。
• 和业务方共背（影响）：核心接口 P99 改善，但只算 DB 时间占比 > 40% 的那些接口（通过 APM 拆解确认），避免背 GC 和网络锅。
• 不背（易刷）：整体慢查询条数。这个数字太容易操纵，且和业务价值脱钩。

核心逻辑：KPI 应该对齐"落地成本与收益"，而不是对齐"容易量化的数字"。消灭 100 条后台慢 SQL 的落地成本（改 SQL + 回归测试 + 上线）和收益（用户感知为零）严重不匹配，如果 KPI 只考核条数，理性人一定会优先做这种"低成本低感知"的事。

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

1. 你们团队 DBA / 后端 / SRE 之间，慢查询治理的 KPI 边界怎么划？谁背"发现"、谁背"修复"、谁背"验证"？
2. "慢查询"的阈值你们怎么定？统一 200ms？按接口分级（OLTP 50ms / OLAP 2s）？有没有踩过"阈值定错了导致治理方向跑偏"的坑？
3. 有没有遇到过"慢查询清零了但 P99 没改善"或"慢查询没清零但 P99 大幅改善"的案例？背后的根因是什么？
4. 季度 OKR 里，你们给慢查询治理留多少人力？是"顺手治"（谁碰到谁修）还是"专项攻坚"（DBA 集中一周扫 Top 50）？哪种 ROI 更高？
5. 如果只能选一个指标写进 OKR，你选哪个？为什么？