慢查询该 DBA 兜底还是业务方自管：你们团队的责任边界到底怎么划？

背景

做了 5 年 DBA，被问得最多的一句话是："这条 SQL 慢，你给加个索引不就完了？" 但换个场合，领导又会说："DBA 是要兜底整个库的性能的。" 这两句话同时成立，就变成 DBA 一个人既当裁判又当运动员：既要劝业务方改写法，又要在半夜被拉起来加索引。我越来越觉得，慢查询治理这件事，先于技术的是责任划分——划不清，加多少索引都不够。

常见分歧 / 几种做法

我见过团队大致落在四种姿势里：

1. DBA 全兜底：业务方只管写 SQL，慢了就找 DBA 加索引、改参数。好处是业务方省心；代价是业务方对性能零感知，索引越加越多，最后 EXPLAIN 出来全是 "Using index condition" 堆出来的假象，回表一抖 P99 直接起飞。
2. 业务方自管，DBA 只做评审和巡检：上线前 SQL 必须过 DBA 评审，慢日志每天扫，问题回到业务方改。好处是责任清晰；代价是评审成了瓶颈，DBA 排期一长业务方就绕过去直接上线。
3. 自动化门禁 + DBA 抽检：把慢查询阈值、索引覆盖、EXPLAIN 关键字段（type、rows、Extra）做成 CI 卡点，PR 不过不让合；DBA 只做抽检和兜底。好处是规模化；代价是误报多，业务方会骂"CI 比 DBA 还烦"。
4. 按表/库划界：核心表（订单、账务、用户）DBA 深度参与，边缘表业务自管。好处是精力聚焦；代价是"核心"的判定本身就会吵架。

我的倾向与理由

我个人倾向 2 + 3 的组合：核心表走 DBA 深度评审 + 自动化门禁兜底，边缘表业务自管 + 慢日志巡检。理由有三：

• DBA 全兜底会掩盖业务方的性能意识，索引越加越多，最后没人知道哪条索引是谁加的、为什么加、能不能删。我见过一张表 17 个二级索引，INSERT 反而成了瓶颈。
• 纯业务自管会漏掉跨表、跨库、跨实例的问题，比如分库路由、主从延迟、连接池打满，这些不是单个开发能看到的。
• 自动化门禁能降低 DBA 评审压力，把 80% 的低级问题（全表扫、SELECT *、隐式类型转换）在 PR 阶段拦掉，DBA 只处理剩下 20% 真正需要权衡的。

但我也有顾虑：门禁误报会让业务方绕过（直接走紧急发布），所以门禁必须可申诉、可豁免，而且豁免要留痕。

想听大家

1. 你们团队慢查询的责任是怎么划的？DBA 背不背 P99 KPI？
2. SQL 评审通过率大概多少？被拒最多的 Top 3 原因是什么？
3. 自动化门禁你们做到什么粒度？是只卡 EXPLAIN，还是连 INSERT 的索引写放大、UPDATE 的行锁范围都算？
4. 有没有"DBA 兜底兜出问题"或"业务自管漏出问题"的真实案例？

欢迎把你们团队的边界线、门禁规则、甚至被拒 SQL 的例子（脱敏后）贴出来，我这边有几个典型 case 可以接着聊。