批量UPDATE不加控制会卡死SQL线程，因大事务导致从库SQL线程串行阻塞、Exec_Master_Log_Pos冻结而Seconds_Behind_Master飙升；须用主键范围分批、显式事务、索引优化及并行复制正确配置来解决。
直接结论：批量UPDATE不加控制，必然卡死SQL线程——不是延迟问题，是复制链路的单点阻塞。
为什么大事务会让从库Seconds_Behind_Master狂涨但Exec_Master_Log_Pos不动
从库SQL线程是串行回放relay log的（即使开了并行复制，单个大事务内部仍必须串行执行）。一个UPDATE涉及10万行，就会持有10万行X锁+间隙锁，持续几十秒甚至几分钟。这期间SQL线程状态是Waiting for dependent transaction to commit或Reading event from the relay log，Exec_Master_Log_Pos几乎冻结，Seconds_Behind_Master却每秒+1、+2地跳。
这不是网络慢、磁盘IO差，而是架构层面的串行化瓶颈。你看到的“延迟”，其实是SQL线程被钉死在一条语句上。
- 查证方式：在从库执行
SHOW SLAVE STATUS\G，重点看Slave_SQL_Running_State和Exec_Master_Log_Pos是否长期停滞 - 确认主库是否存在活跃大事务：
SELECT trx_id, trx_started, trx_rows_modified FROM information_schema.INNODB_TRX WHERE trx_rows_modified > 10000 - 别信
Seconds_Behind_Master = 0——它在大事务执行中会误报“正常”
用主键范围分批UPDATE，而不是LIMIT OFFSET
LIMIT 500 OFFSET 1000看着是分页，但MySQL执行时仍要扫描前1500行，锁范围不可控，且OFFSET越大越慢。真正安全的是基于主键值的确定性切片。
- 先查出一批ID：
SELECT id FROM t WHERE status = 'pending' ORDER BY id LIMIT 500 - 再用
WHERE id BETWEEN ? AND ?更新，起始值取上一批的MAX(id)，避免漏或重 - 每批严格控制在100–500行；若涉及多表JOIN或大字段，建议缩到100以内
- 每批后必须
COMMIT，并加SLEEP(0.01)缓解锁争抢和CPU压力 - WHERE条件必须能走索引——用
EXPLAIN确认type不是ALL，避免隐式转换（如VARCHAR字段传数字）
并行复制开了也卡？检查这三个配置是否配对生效
只设slave_parallel_workers > 0没用。并行复制需要三者协同：
-
slave_parallel_type必须为LOGICAL_CLOCK（5.7+）或WRITESET（8.0+），不能是DATABASE——后者对单表大事务完全无效 - 主库
binlog_format必须为ROW，且binlog_order_commits保持ON（默认值，别关） - 验证是否真跑起来：
SELECT * FROM performance_schema.replication_applier_status_by_worker，看LAST_SEEN_TRANSACTION是否非空；全为空说明并行没启用
最容易被忽略的“伪大事务”：autocommit=1下的循环操作
代码里没写BEGIN，但循环中反复执行INSERT/UPDATE又不COMMIT，autocommit=1时每句都是独立事务——看起来小，实际因网络延迟、锁排队、binlog刷盘开销，累积效应远超单一大事务。
这类问题在应用层日志里看不到长事务，但在从库SHOW PROCESSLIST里能看到大量Updating状态堆积，Exec_Master_Log_Pos缓慢爬升。
- 修复方式：显式
START TRANSACTION+ 批量操作 +COMMIT，把N个小事务合并为可控批次 - 禁止在循环内做单行
UPDATE，尤其不能用SELECT ... FOR UPDATE锁单行再更新——极易引发间隙锁扩散 - 所有多表操作必须约定唯一顺序（如按表名字母序：
order_item → order → user），否则死锁概率极高
真正难的不是写对语法，而是让每个批量操作都可中断、可重入、可追溯。比如每次分批更新后，必须把最后处理的id写入临时表或文件，否则服务重启就漏数据或重复。这点在容器化部署中尤其容易被绕过——配置挂载错、临时目录不持久、健康检查杀掉正在运行的批处理脚本……细节一塌糊涂，再好的方案也白搭。
