大事务卡住SQL线程的本质是MySQL从库SQL Thread必须串行原子化重放整个事务，无法拆分或并行；需通过SHOW SLAVE STATUS检查Exec_Master_Log_Pos停滞、SHOW PROCESSLIST确认SQL Thread长时间Executing，并在主库INNODB_TRX中定位trx_rows_modified>10000且trx_started超30秒的事务。
大事务让SQL线程卡住的本质原因
因为MySQL从库的SQL Thread必须串行重放整个事务，不能拆开、不能跳过、也不能并行——哪怕主库是分批提交的，只要它在一个BEGIN...COMMIT里，从库就只能当一个原子单元处理。事务越大（比如修改10万行+含LONGBLOB字段），SQL线程就越久停在“executing”状态，期间Seconds_Behind_Master飙升，但Slave_SQL_Running_State仍显示Executing，不是报错，而是真·不动。
怎么确认卡住的是大事务而不是其他问题
别只看Seconds_Behind_Master，它可能为0却已严重滞后。关键要看：
-
SHOW SLAVE STATUS\G中Exec_Master_Log_Pos长时间不更新，而Relay_Log_Space持续上涨 → 说明SQL线程卡在解析/回放阶段 -
SHOW PROCESSLIST里SQL Thread状态是Executing，且Time值远大于普通查询（比如>60s） - 主库查
information_schema.INNODB_TRX，发现trx_rows_modified > 10000且trx_started早于当前时间30秒以上 → 这就是源头的大事务
大事务卡住时为什么并行复制也无效
MySQL的并行复制（slave_parallel_workers > 0）按事务粒度划分Worker，不是按行。一个未提交的大事务，无论多长，都会被分配给同一个Worker，其他Worker干等着。尤其在WRITESET或LOGICAL_CLOCK模式下，只要事务没提交，它的所有event就被视为强依赖，无法拆分调度。
更麻烦的是：如果这个大事务还包含DDL（如ALTER TABLE），整个relay log流会直接阻塞，后续所有事务都排队——哪怕它们彼此无关。
最容易被忽略的隐性大事务场景
很多卡顿不是来自显式BEGIN，而是ORM或ETL工具造成的“伪大事务”：
- Django的
bulk_create()默认不自动分批，一次传5万条 → 实际生成一个事务 - MyBatis的
<foreach>没设batchSize，循环INSERT全堆进一个事务 - DataX或Flink CDC配置了
batchSize=10000但maxFetchSize设成0 → 拉取时全加载到内存再提交 - 存储过程中用
WHILE循环UPDATE却不COMMIT→ 隐式事务越滚越大
这些情况不会在慢日志里报慢，却会让SQL Thread在从库默默卡住几分钟甚至更久——直到OOM或超时中断。
