结论先行：批处理把在线业务拖慢，90% 不是「SQL 写错了」，而是「上线前没人回答三个问题」——它最该跑多快（吞吐预算）、它和在线共享哪些资源（影响面）、它挂了/没跑完怎么办（失败处置）。我 15 年做技术产品，见过 4 起「批处理撞在线」的事故，根因没有一起是 bug，全是这三个问题里漏答了至少一个。这篇给一套可以直接抄进上线 checklist 的框架，附具体数字和公式。
一、现象：一次「按规范执行」的批处理，把在线 P99 打到 25 倍
先交代规模，方便后面判断量级：
- 库：MySQL 8.0.32（InnoDB，RC 隔离级别），8C32G，
innodb_buffer_pool_size=24G；核心宽表t_task_item约 1.4 亿行，主键id。 - 在线写入：任务状态机翻转（提交 / 完成 / 失败），约 2000 TPS，全部是
UPDATE t_task_item SET status=?, modified_at=? WHERE id=?等值 PK 更新，平时 P99 = 2.4ms。 - 批处理：每月 1 号凌晨 1:00–5:00 跑「逾期任务批量归档」，8 worker，5000 万行，团队按「教科书写法」——
FOR UPDATE SKIP LOCKED取活 + 500 行/批提交。 - 事故曲线（Prometheus 1 分钟粒度）：
- 1:00:00 批处理点火，在线 P99 从 2.4ms 爬升；
- 1:07 到 1:28 这 21 分钟：在线 P99 稳定在 61ms（25 倍），QPS 从 2000 掉到 1380（-31%）；
- 窗口内死锁计数 38 次，其中 34 次回滚的是在线侧事务（
WE ROLL BACK TRANSACTION那行别读错，下面第四段会讲）； - 客服工单 14 条，全是「提交任务转圈 / 重复提交」；
- 值班同学 1:28 手动 kill 全部 worker 后，P99 在 90 秒内回落到 2.5ms——这个「kill 即恢复」的曲线是批处理争用类故障的指纹：资源一松，在线立刻回血。
诡异且最迷惑的一点：慢查询日志（阈值 100ms）里在线 UPDATE 一条都没有，buffer pool 命中率全程 ≥ 99.9%，应用 CPU 没超过 40%。所有「看起来该报警的指标」都没报警，只有 P99 曲线在尖叫。
二、原理：为什么「没慢 SQL、没长事务、CPU 不高」照样能拖垮在线
把机制拆成三个叠加的共享资源，每个都给出量化判断：
1) 行锁争用：碰撞密度决定一切。 批处理每轮 500 行里，平均 6–9 行落在在线活跃写入集合（正在翻转 status 的任务行）。8 worker × 每 worker 约 40 轮/s 的取活频率，意味着每秒 1900–2900 次「批处理锁触达在线活跃行」事件——已经超过在线 2000 TPS 的有效写入。一旦批处理锁触达速率 ≥ 在线写入速率，在线事务就从「偶尔等锁」变成「持续排队 + 死锁回滚 + 客户端重试」，P99 断崖式劣化，但单次 SQL 执行依然 < 100ms，所以慢日志干净。这个「P99 飙但慢日志干净」的组合，是锁争用类故障的第一指纹。
2) buffer pool 是共享内存，批处理扫描会挤占在线热页。 批处理按 idx_status_modified 顺序扫 5000 万行，即使走覆盖索引，回表和索引页的读写也要过 buffer pool。我们事后用 performance_schema.table_io_waits_summary_by_table 对比发现：批处理窗口内 t_task_item 的读页数从基线的 ~1200 页/s 涨到 3.1 万页/s，在线热页（最近 5 分钟内被写入的行）命中率从 99.8% 掉到 96.2%——3.8% 的在线更新变成了随机 IO。单看这点不致命，但和锁争用叠加，尾延迟就爆了。
3) 死锁回滚的不对称性：InnoDB 回滚「代价小」的那一方，而在线事务通常代价最小。 批处理事务里已持有 500 行锁、回滚代价大；在线事务只持 1 行锁，回滚代价小——于是 38 次死锁里 34 次回滚的是在线侧。业务上完全无辜，但要向用户道歉的是我们。
一句话：批处理和在线共享三样东西——行锁、buffer pool 内存、磁盘 IO。任何一个的争用密度过了拐点，P99 就崩；而拐点不是线性的，是「批处理锁触达速率 ≈ 在线 TPS × 3」附近陡降的（见第三段）。
三、具体做法：上线前必须回答的三个问题 + 可复现配置
问题 1：它最该跑多快？（吞吐预算）
公式：批处理锁触达速率（行/s）≤ 在线写入 TPS × 3。
- 在线 2000 TPS → 上限 6000 行/s；
- 8 worker → 每 worker 750 行/s；
- 每批 500 行 → 每 worker 每批后
sleep约 66ms（500/750 ≈ 0.66s 一批，取批间 sleep 660ms 的 1/10 修正——实际我们按令牌桶实现，见下）。
// Guava RateLimiter，全局共享 6000 permits/s（= 在线 2000 TPS × 3）
RateLimiter batchPermit = RateLimiter.create(6000.0);
void runBatchShard(int shardId) {
while (running) {
batchPermit.acquire(); // 限速点：拿不到许可就阻塞
List<Long> ids = mapper.selectShard(shardId, cutoff, 500);
if (ids.isEmpty()) break;
int affected = mapper.casUpdate(ids, batchTs, cutoff); // 见下
checkpoint(shardId, lastId(ids), affected);
}
}
CAS 条件写进 UPDATE（零成本最佳实践，所有批量 UPDATE 都应带）：
UPDATE t_task_item
SET status = 'ARCHIVED', modified_at = :batch_ts
WHERE id IN (:ids)
AND status = 'PENDING'
AND modified_at < :cutoff; -- 关键：带 CAS 条件，在线翻转后 modified_at 变新，
-- 批处理 affected=0，从「抢锁等锁」降级为「条件落空」
时间窗口反推：5000 万行 ÷ 6000 行/s ≈ 222 分钟 ≈ 3.7 小时，4 小时窗口（1:00–5:00）刚好够，多留 7% 余量。如果窗口不够，第一反应不是提速，是延长窗口或拆到两天——提速意味着抬高限速阈值，直接撞在线 P99 的拐点。
问题 2：它和在线共享哪些资源？（影响面清单）
上线前必须书面回答，我们的模板：
| 共享资源 | 批处理用法 | 与在线的碰撞面 | 判定 |
|---|---|---|---|
| 行锁 | 每批 500 行 X 锁 | 碰撞率 = 批触达行 ∩ 在线活跃行 / 批触达行 | 6–9/500 ≈ 1.6% > 1/100 警戒线 → 必须分片 + 限速 |
| buffer pool | 顺序扫 5000 万行索引页 + 回表 | 在线热页被挤出 | 限速到 6000 行/s 后读页数 1200 → 3800 页/s，可接受 |
| 磁盘 IO | 冷数据读取 | 在线随机写 | 错峰到 1:00，避开 0 点整点任务群（见第五段坑 4） |
| 连接池 | 8 worker × 2 连接 = 16 | 与在线 50 连接共享 max_connections=300 | 批处理窗口内连接占用 5%，可接受 |
分片是限速的前置条件（顺序不能反）：
-- worker 只处理自己的 id 区间，物理上不碰其他 worker 的行
SELECT id FROM t_task_item
WHERE id BETWEEN :shard_lo AND :shard_hi
AND id % 8 = :shard_id
AND status = 'PENDING'
AND modified_at < :cutoff
ORDER BY id
LIMIT 500;
分片后 FOR UPDATE SKIP LOCKED 可以整个去掉——它只解决「worker 间不撞车」，不解决「worker 和在线撞车」。
问题 3：它挂了/没跑完怎么办？（失败处置）
checkpoint 表（每批提交后写一次）：
CREATE TABLE t_batch_checkpoint (
job_name VARCHAR(64) NOT NULL,
shard_id TINYINT NOT NULL,
last_id BIGINT NOT NULL,
rows_done BIGINT NOT NULL DEFAULT 0,
updated_at DATETIME NOT NULL,
PRIMARY KEY (job_name, shard_id)
);
失败策略（我们定的三条规矩）：
- 首错不自动重试，只告警（PagerDuty 电话）。理由：自动重试 = 在未确认根因的情况下再撞一次共享资源，4 起事故里 3 起是重试放大。人工 5 分钟内确认后再决定重试 / 跳过 / 终止。
- kill 后 30 分钟内不允许同 job 重新点火（调度器侧冷却时间），防止值班同学「kill 一下再跑一下」的肌肉记忆。
- 窗口跑不完 → 自动顺延到次日同窗口，而不是提速补跑。补跑提速 = 抬高限速阈值 = 撞在线拐点，这是最危险的「看起来合理」的操作。
四、踩过的坑与反直觉之处
- 「出现在死锁报告里」≠「没被回滚」。
SHOW ENGINE INNODB STATUS的LATEST DETECTED DEADLOCK输出的是检测方的两个事务；谁被回滚要看*** WE ROLL BACK TRANSACTION (x)那一行。我们第一次复盘时把「批处理 SQL 出现在死锁报告里」当成「批处理是赢家」，实际 34/38 次回滚的是在线侧——这个误读直接导致了第一轮改造方向错了（去调隔离级别，毫无效果）。 - 限速阈值存在陡拐点，不是线性关系。 我们实测：6000 行/s 时在线 P99 = 2.6ms（基线 ±10%）；提到 12000 行/s（在线 2000 TPS × 6）时，P99 立刻跳到 18ms 且死锁 23 次/窗口；再提到 24000 行/s，P99 = 41ms。拐点位置约等于「批处理锁触达速率 ≈ 在线 TPS × 3」，超过后每翻倍，P99 不是翻倍，是跳档。所以 6000 行/s 不是「保守估计」，是物理边界。
- RC 隔离级别不是免死金牌。 我们库是 RC，gap lock 已不存在，事故照样发生——因为根因是「锁窗口 + 碰撞密度」，不是隔离级别。隔离级别只决定锁的范围，不决定锁的持有时间和碰撞概率。
- 1:00 这个窗口不是随便选的。 我们同一套库上还有 31 个整点 cron 任务（00:00 和 01:00 各 15 个以上），批处理如果定在 00:00，会叠加在「整点任务群」的 IO 尖峰上——错峰之前先查全库的 cron 表达式分布，选一个「邻居最少」的窗口。这次选 1:00 是因为 1:00 整点任务只有 6 个（查的
crontab -l全量统计），00:00 有 22 个。 sleep拍脑袋会翻车。 最初版本用Thread.sleep(200)拍脑袋限速，结果实际吞吐 8 worker × 500 行/0.7s ≈ 5700 行/s——看起来在 6000 以内，但因为 sleep 精度 + GC 停顿，实际锁触达速率抖动到 9000 行/s，P99 还是飙了。换成令牌桶（RateLimiter.create(6000.0)）后，速率稳定在 6000 ± 3%，P99 才真正回到基线。限速必须用令牌桶 / 漏桶等确定性算法，sleep 只适合原型验证。
五、结论与可复用清单
三个问题，一张 checklist，上线前逐条打勾：
- [ ] 吞吐预算：批处理锁触达速率 ≤ 在线 TPS × 3？（写出算式，不是拍脑袋）
- [ ] 碰撞率：批触达行 ∩ 在线活跃行 / 批触达行 < 1/100？（用 SQL 统计，不是估算）
- [ ] 分片：worker 间物理分片（
id % N或区间）已完成？（SKIP LOCKED 可去掉） - [ ] CAS 条件：批量 UPDATE 带
modified_at < :cutoff？（零成本，必带） - [ ] 限速算法：令牌桶 / 漏桶，不是 sleep？（确定性限速）
- [ ] 窗口反推：总行数 ÷ 限速阈值 ≤ 窗口时长 × 0.9？（留 10% 余量）
- [ ] 影响面清单：行锁 / buffer pool / IO / 连接池四项逐一书面判定？
- [ ] checkpoint：每批提交后写进度？（断点续跑）
- [ ] 失败策略：首错告警不自动重试？kill 后 30 分钟冷却？跑不完顺延不提速？
- [ ] 错峰：目标窗口内其他 cron 任务 ≤ 10 个？（全库 crontab 统计）
- [ ] 监控：批处理窗口内同屏盯「在线 P99 + 批处理行/s + 死锁计数 + 锁等待时长」四个指标？
- [ ] 指纹识别：值班同学认得「P99 飙 + 慢日志干净 + kill 即恢复」= 批处理争用？
一句话总结：批处理不是「跑完就行的后台任务」，它是在线业务共享资源上的一个并发参与者——上线前必须像对待一个新上线的在线服务一样，给它算吞吐预算、画影响面、写失败预案。三个问题回答完，再点火。
（本文机制分析参考了站内两篇批处理与在线争用的实战复盘，见文末引用。）