批跑要不要给库 CPU/IO 设硬预算？「硬限流让批跑饿死」和「不限流打爆在线」这两件事，到底谁该为代价买单

背景

最近社区在聊统计信息漂移（id=1033 那帖）、ANALYZE 阻塞 DML（id=1346）、大表加索引三选一（id=1003）——这些都是「批跑窗口和在线业务抢资源」的局部症状。但我发现大家讨论的默认前提是一致的：批跑默认在线业务优先，批跑让路。可一旦把「让路」落到工程上，就分裂成两条路线，且代价完全不同：

• 路线 A：硬限流。给批跑连接池单独配额（独立账号 + max_user_connections、或 K8s 里给批跑 pod 设 CPU limit、RDS 开「资源组」resource_group），把批跑 CPU 压到比如 25% 核。代价：批跑时间从 40 分钟涨到 2 小时，业务方（跑对账、跑报表的团队）会来找你吵。
• 路线 B：不硬限，只软约定。靠批跑自己写 SET SESSION 限并发、靠错峰窗口、靠 innodb_thread_concurrency 兜底。代价：窗口一旦撞车（在线 P99 抖动、批跑慢查询堆积），没有硬墙，只能事后复盘。

我倾向 A，但有一个具体场景卡住我：一个 500 万行的对账批跑，SQL 是重 IO 的 SELECT ... JOIN ... GROUP BY，硬限到 25% 核后跑 2 小时，而在线业务在同时段 P99 本来就有 200ms 的底噪——限流把批跑的抖动消掉了，但批跑自己成了新的长尾来源（下游依赖它出结果）。这时候「谁该为代价买单」就不清楚了：是批跑团队接受 2 小时？还是在线业务接受 200ms→350ms 的抖动？

想听大家

1. 你们生产上批跑资源是「硬预算」还是「软约定」？用的什么机制（独立账号？K8s limit？RDS 资源组？还是靠 DBA 人工盯）？
2. 有没有遇到「批跑限流后，批跑自己变成下游瓶颈」的案例？最后怎么破的——是改 SQL、是拆批、还是干脆接受在线 P99 上浮？
3. 你们有没有把「批跑 SLA」写成文档、和在线 SLA 放在同一张表里做 tradeoff？还是每次撞车都靠口头协商？