慢 SQL 治理：你的团队是「先 kill 还是先治」？超时阈值到底是兜底还是主方案？

【背景】

做了 3 年数据库平台，慢查询治理是绕不开的事，但每次跟团队对齐策略，都会撞上一堵墙：

慢 SQL 来了，我们的第一反应是什么？

我见过三种明显不同的团队文化：

A.「超时优先」型 核心链路默认 max_execution_time = 500ms，超时就 kill，先保 P99 不被拖垮，根因后面再说。 典型逻辑：「慢查询是异常，异常就该被快速熔断，不能让它影响其他请求。」 这套思路的好处很直接——实现成本低，保护效果即时，不需要等工程师排期。

B.「根因优先」型 认为超时只是止血带，真正的解法是加索引 / 改 SQL / 读写分离，否则治标不治本。 典型逻辑：「如果我们靠超时来兜底，说明这个查询计划本来就不该出现在这条链路上。」 这套思路的问题是：改 SQL 动辄 1–2 周排期，加索引有写放大成本，短期风险敞口很大。

C.「两手抓」型（大多数团队） 超时兜底 + 根因修复并行，但往往缺乏清晰的优先级排序——哪条慢 SQL 先治、哪条先靠超时扛着，没有统一标准。

【我的倾向】

我倾向 C，但有一个关键区分：超时是「未知慢查询」的保险丝，修复是「已知慢查询」的解法，两者的适用对象不同，不应该混为一谈。

• 对核心交易链路：超时阈值应该偏激进（100–300ms），同时已知慢 SQL 必须在 1 个迭代内完成根因修复；
• 对批量 / 分析类查询：可以放宽到秒级，但必须有资源隔离（独立实例或 read replica），不能和在线流量混跑；
• 最大的坑：很多团队的 max_execution_time 是上线时拍的一个值，之后再没人动过，导致要么误杀合法长查询，要么完全没起到保护效果。

【想听大家聊的】

1. 你们核心链路的超时阈值具体是多少？是按 query 类型差异化配置，还是全局一个值？
2. 慢 SQL 治理的优先级排序，你们用什么标准？影响面（多少请求受影响）/ 频率 / 开发成本，哪个权重最高？
3. 有没有遇到过「加了索引之后写路径变慢」的典型案例？你们怎么权衡的？
4. 你们有 per-query 的超时配置机制吗，还是全靠连接池级别的全局值？

有具体场景 / 配置截图的欢迎贴出来，比抽象讨论有用。