大事务导致从库延迟飙升因单线程SQL Thread串行回放ROW格式长事务应分批UPDATELIMIT游标、避免子查询、用GTID差值等精准监控延迟。大事务为什么让从库延迟飙升主库一个 UPDATE 改 50 万行binlog 里就是一条长事务日志从库只能串行回放——不是它不想快是 MySQL 的复制线程SQL Thread默认单线程重放卡在这条事务上后面所有日志都得排队。你看到的 Seconds_Behind_Master 突然跳到几千秒往往就源于此。常见错误现象SHOW SLAVE STATUS 里 Seconds_Behind_Master 持续上涨、Exec_Master_Log_Pos 几乎不动、Slave_SQL_Running_State 停在 executing event同时主库 SHOW PROCESSLIST 早结束了但从库 SHOW PROCESSLIST 还卡着一条 Update_rows_log_event 或 Query_log_event。关键点不是数据量大就一定慢而是「单个事务内修改行数多 行锁时间长 binlog 格式为 ROW」三者叠加最容易触发同步瓶颈。怎么拆用 LIMIT WHERE 分批提交别信 OFFSET直接 UPDATE ... LIMIT 1000 是最常用也最稳妥的拆法但必须配合确定性排序和游标式推进否则会漏行或重复。正确姿势先加索引确保 WHERE 条件字段有高效索引比如 status pending且 status 上有索引用自增主键或时间戳做游标比如 WHERE id 100000 AND status pending ORDER BY id LIMIT 1000每次取完记录最大 id下一轮从它开始每次执行后显式 COMMIT确保每个分片是独立事务绝对不用 LIMIT 1000 OFFSET 10000OFFSET 越大越慢且并发时可能跳过或重复示例片段伪代码SET last_id 0;WHILE (SELECT COUNT(*) FROM orders WHERE id last_id AND status pending) 0 DO UPDATE orders SET status processed WHERE id last_id AND status pending ORDER BY id LIMIT 1000; SELECT last_id : MAX(id) FROM orders WHERE id last_id AND status processed LIMIT 1; COMMIT;END WHILE;ROW 格式下避免全表 UPDATE尤其带子查询ROW 格式 binlog 会记录每一行变更前后的镜像如果 UPDATE t1 SET a(SELECT b FROM t2 WHERE t2.idt1.id) 扫了 10 万行binlog 就写 10 万条 Update_rows_log_event体积暴涨网络传输解析都变慢。 AI智研社 AI智研社是一个专注于人工智能领域的综合性平台