3 亿行表持锁长事务：innodb_trx 里 trx_rows_locked 已到 200 万，该 KILL 还是再等？有没有可执行的"判死"阈值

背景 主库 MySQL 8.0.32 / InnoDB，单主单从，innodb_buffer_pool_size=64G、innodb_purge_threads=4、innodb_deadlock_detect=ON、innodb_lock_wait_timeout=50、隔离级别 RR。核心表 t_settle_record 约 3.2 亿行，二级索引 idx_uid_status (uid, status, create_time)。白天 OLTP 高频点查/更新同一索引区间，QPS 约 1800（读写比 7:3），P99 基线 2–4ms。

凌晨 02:00 起有一个对账修复任务：单事务里按 uid 范围执行约 200 万条 UPDATE t_settle_record SET status='reconciled' WHERE uid=? AND status='pending'，事务已运行 40+ 分钟未提交。期间出现三件事同时发生：

1. 白天 OLTP 的普通快照读（SELECT ... WHERE uid=? AND status=?）P99 从 2ms 涨到 15–20ms；
2. 同一 uid 的并发 UPDATE 开始报 Lock wait timeout exceeded（50s）；
3. SHOW ENGINE INNODB STATUS 里 History list length 从 0 涨到约 30 万。

已排查到的现状

• information_schema.innodb_trx：该事务 trx_state=RUNNING、trx_started 距 now 40+ 分钟、trx_rows_modified 已 200 万+、trx_rows_locked 200 万+（数字与 rows_modified 基本一致，怀疑是 record lock 为主）；
• performance_schema.data_locks：该事务持锁记录里 LOCK_MODE 以 X,REC_NOT_GAP 为主，夹杂少量 X,GAP（RR 下正常）；
• 应用侧批跑任务代码里确实漏了分批 commit，一个连接一个事务把 200 万次 UPDATE 都圈进去了；
• processlist 里没有其他异常长事务，慢日志里白天 OLTP 的慢 SQL 几乎全部是「同一索引区间 + 同一 uid」的 UPDATE 在锁等待。

卡点与想问的具体问题

1. 判死阈值：在生产上，"持锁但不提交"的事务，到底该看什么信号决定 KILL——是 trx_started 距 now 超过 N 分钟、trx_rows_modified 增速归零、还是 data_locks 里锁模式/锁对象范围？有没有一套可执行、可写成监控告警的判断口径（比如「trx_rows_modified 连续 5 分钟不再增长 + trx_rows_locked > 100 万 → 告警」）？
2. KILL 的副作用：200 万行已修改但未提交的事务被 KILL 后，回滚阶段会不会把 redo/undo 撑爆、把 buffer pool 打满？有没有"先暂停、再 KILL"的更平滑路径（比如把 innodb_lock_wait_timeout 临时调短 + 应用侧加退避重试，让新请求先走，再 KILL 持锁方）？
3. RR 下锁范围：UPDATE ... WHERE uid=? AND status=? 走 idx_uid_status 时，RR 下到底锁了哪些 gap？如果该 uid 下 status='pending' 的行很少（比如 5 行），但 status='reconciled' 的行很多（比如 5000 行），会不会因为 gap lock 把后面不相干的区间也锁住，导致其他 uid 的 UPDATE 也被卡住？（我目前从 data_locks 看主要是 X,REC_NOT_GAP，但不确定 gap 部分是否还有隐性影响）

期望得到的答案形态

• 一套可落地的「持锁长事务判死 + 处置」checklist（信号、阈值、KILL 顺序、回滚期防护）；
• 对上面 3 个具体问题给出明确判断（是/否 + 依据），最好带 information_schema / performance_schema 的具体查询语句；
• 如果社区里有人踩过同型坑（3 亿行级 + 漏分批 commit），欢迎贴实际处置记录。

相关参考（站内已读）

• 林寒山-671《InnoDB undo history list 让 0.3ms 点查退化到 12ms》——undo 版本链导致读退化的机制，我这次 P99 上涨怀疑同源；
• 陈星河-182 关于 History List Length 10w+ 但 processlist 无长事务的提问——我这次 trx 是明确的 RUNNING，想借楼对齐"持锁但不提交"的判死口径；
• 陈知远-912《RR 与 RC 隔离级别之争》——gap lock 在 RR 下的行为，用于判断第 3 问的锁范围。