根本原因是SQL线程原子性回放事务，必须等大事务全部执行完才更新Seconds_Behind_Master和Exec_Master_Log_Pos，导致relay log积压、监控失真、后续binlog排队等待。
大事务提交时主从延迟急剧增加，根本原因不是“事务太大”，而是 MySQL 复制线程的执行模型被卡死：SQL 线程必须等整个事务全部回放完，才更新 Seconds_Behind_Master 和 Exec_Master_Log_Pos。这期间所有后续 binlog 都在 relay log 里排队，监控却可能显示“0 秒延迟”。
为什么大事务会让 SQL 线程“冻结”30秒甚至更久
MySQL 的 SQL 线程（或 MTS 下的 worker）对每个事务是原子性回放的。一个 INSERT INTO t SELECT * FROM huge_table WHERE ... 执行 28 秒，那这 28 秒内：
- 从库不会推进
Exec_Master_Log_Pos，Seconds_Behind_Master停摆或滞后严重 - 主库新产生的 binlog 全部积压在 relay log 文件里，无法消费
- 监控工具（如
pt-heartbeat）若只依赖Seconds_Behind_Master，会误判为“正常” - 如果该事务持有 MDL 锁或行锁，还可能阻塞其他小事务的回放（尤其在
slave_preserve_commit_order=1时）
大事务本身不写 binlog 慢，但会拖垮整个提交节奏
很多人以为大事务延迟是因为 binlog 写得慢——其实不然。关键在于 binlog 的 提交顺序 和 GTID 分配机制：
- 大事务占用一个 GTID，且必须等它完整提交后，下一个事务才能获得下一个 GTID 并写入 binlog
- 主库上多个小事务被“攒”在大事务后面，无法及时落盘，导致 binlog 生成速率人为压低
- 从库只能串行消费这些 GTID，无法并行——即使开了
slave_parallel_workers，只要事务间有依赖（比如同 DB、同表），仍会被串行化 -
binlog_format=ROW下，大事务产生巨量 row event，进一步加重从库解析和应用压力
常见误判：看到 Seconds_Behind_Master = 0 就以为没延迟
这是最危险的认知偏差。当一个大事务正在从库回放时，Seconds_Behind_Master 可能长时间卡在旧值（比如 2 秒），直到事务结束才跳到 30+ 秒。此时真实延迟早已远超显示值。
- 真正可靠的指标是：
Read_Master_Log_Pos - Exec_Master_Log_Pos差值持续扩大 → 表明 relay log 积压 - 配合
SHOW PROCESSLIST查看 SQL 线程状态：若显示Reading event from the relay log但长时间不动，大概率卡在某个大事务里 - 用
SELECT * FROM performance_schema.replication_applier_status_by_worker查各 worker 进度，确认是否某 worker 长期停滞
最容易被忽略的复合影响点
大事务不是孤立问题，它常和其它配置/环境因素叠加放大延迟：
- 从库
innodb_flush_log_at_trx_commit=1+ 机械盘 → 单次事务 fsync 耗时翻倍，10k 行插入可能要 5 秒以上 - 目标表缺失索引 →
INSERT ... SELECT回放时触发 filesort 或临时表，CPU 和 IO 双重打满 - 主库用了
binlog_row_image=MINIMAL，但从库表结构多了字段 → 回放失败或降级为全字段比对，性能骤降 - 事务中混用 DML 和 DDL（如先
UPDATE再ALTER TABLE）→ 从库可能因 MDL 锁等待数分钟
真正要盯的不是“有没有大事务”，而是“有没有不可拆分、无索引、跨时段、带 DDL 的大事务”。这类事务一旦上线，延迟就不是“会不会发生”，而是“何时爆发”。
