大事务不会导致Slave_SQL_Running为No，但会使SQL线程长期卡在Executing event或Waiting for dependent transaction to commit，位点停滞、Seconds_Behind_Master失真、Relay_Log_Space暴涨，并行复制退化为单线程，本质是事务原子性导致的“假活”而非中断。
大事务不会直接导致复制“中断”，但会让SQL线程卡死在执行中
MySQL主从复制中断（Slave_SQL_Running: No）通常由报错触发，比如主键冲突、表不存在、DDL失败等；而大事务本身不会报错，它只会让Slave_SQL_Running保持Yes，但Slave_SQL_Running_State长期卡在Executing event或Waiting for dependent transaction to commit。这不是中断，是“假活”——监控显示正常，实际已积压数千条 relay log。
Seconds_Behind_Master 失效：延迟冻结而非缓慢追赶
一个改 300 万行的 UPDATE 在从库执行 42 秒，这期间：
– Exec_Master_Log_Pos 完全不动
– Read_Master_Log_Pos 持续前进（I/O 线程照常拉日志）
– Seconds_Behind_Master 可能维持 0 或旧值长达几十秒，直到事务结束才跳变
– Relay_Log_Space 暴涨（例如从 200MB 涨到 8GB），这是 SQL 线程处理不过来的铁证
本质是 MySQL 的事务原子性要求：SQL 线程必须等整个事务提交后，才更新位点和延迟指标。它不是“慢”，是“锁死”。
并行复制（MTS）在大事务下自动退化为单线程
哪怕你配置了 slave_parallel_workers = 8，只要遇到单个事务（无论多大），所有 worker 都会等待该事务完成——因为事务内操作存在逻辑依赖，不能拆开并行。关键检查点：
-
slave_parallel_type必须是LOGICAL_CLOCK（5.7+）或WRITESET（8.0+），设成DATABASE对单库大事务完全无效 - 查
performance_schema.replication_applier_status_by_worker：如果LAST_SEEN_TRANSACTION全为空，说明并行根本没跑起来 - 主库必须开启组提交：
binlog_group_commit_sync_delay > 0，否则从库收不到可并行的事务批次
真正危险的是“伪大事务”：autocommit=1 下的循环 DML
开发写了个 Python 脚本循环执行 INSERT INTO t VALUES (...)，每句都带 COMMIT（即 autocommit=1）。看起来每条都很小，但问题在于：
- 每条语句生成独立 binlog event，网络传输、解析、回放开销翻 N 倍
- 从库 relay log 写入压力陡增，磁盘 IO 扛不住时触发
Got timeout reading communication packets类错误，最终导致 I/O 线程断连 - 这类脚本往往没加重试/限流，主库一抖动就批量失败，日志里全是
Last_IO_Errno: 2013
最易被忽略的点：事务大小不等于单条 SQL 行数，而取决于它在 binlog 中生成的 event 总量 + 从库回放时的锁竞争强度。一次没索引的 DELETE WHERE status=0 即使只删 1 万行，也可能因全表扫描+逐行加锁，在从库卡住 10 分钟。
