慢查询到底该"杀掉"还是"放它跑完"？数据平台的资源治理你怎么选

背景： 我做了 8 年大数据平台，最近复盘一次事故：凌晨一个 BI 报表任务扫了 40GB 未命中的分区，把共享查询引擎的内存打爆，连带拖垮了两条在线服务链路。事后我们上了「查询级超时 + 资源配额 + 优先级队列」，但团队内部吵了一架：数据团队觉得"杀查询"粗暴，业务方觉得"放它跑完"不可接受。

常见分歧（我观察到的三种典型立场）：

1. 强杀派：查询超过阈值（时间/扫描量/内存）直接 kill，理由是在线 SLA 优先，慢查询是"不合理的 SQL"，应该被拦在提交阶段。
2. 排队派：不杀，但进低优先级队列，等空闲资源再跑。理由是数据查询往往是大表扫描，杀掉重跑成本更高，且用户心理预期是"慢一点也行"。
3. 治理派：不纠结杀不杀，而是在 SQL 入口做静态检查（分区裁剪、行数预估、索引命中），把"注定要慢"的查询挡在门外。

我的倾向： 治理派 + 排队派的组合。理由：

• 强杀的副作用是"用户重试风暴"，杀掉后用户往往立刻重提，反而加重负载；
• 排队派的副作用是"队头阻塞"，一个 20 分钟的查询会让后面 50 个小查询全部等待；
• 静态检查是最便宜的防线，但只对"明显不合理"的 SQL 有效，对"看似合理但数据分布变了"的 SQL 无效，所以还需要兜底。

具体做法（我们线上的配置，供参考）：

• 入口层：EXPLAIN 预估行数 > 1e8 且未命中分区裁剪 → 拒绝提交，返回"请加分区过滤"；
• 运行层：单查询内存配额 8GB，超过即 OOM kill 并记录 fingerprint；
• 调度层：BI 报表进 batch 队列，在线服务进 interactive 队列，资源池物理隔离 30%；
• 兜底层：所有慢查询（>5s）落 SLS，按 fingerprint 聚合，每周 Top20 推给 SQL owner 治理。

想听大家：

• 你的场景里，"杀"和"排队"的比例大概怎么分？
• 在线查询和数据查询共享一个引擎时，你们是怎么隔离的？（资源组？独立集群？时间片？）
• 有没有遇到过"杀了反而更慢"的诡异 case？比如 kill 后事务回滚本身就成了慢操作。
• 你们对"查询超时阈值"是定死一个值，还是按 SQL 类型 / 用户角色动态给？

欢迎贴你的配置、踩过的坑、以及"看起来对但实际翻车"的方案。