大事务卡住sql线程是因为从库必须串行执行完整事务才能推进位点，导致seconds_behind_master飙升、exec_master_log_pos停滞；根治方法是主库端按主键或时间分段、每批5000–10000行、显式begin/commit拆分，并确保slave_parallel_type=logical_clock以激活并行复制。
大事务在主从架构下会卡住 SQL 线程，不是网络慢或磁盘慢，而是从库必须等整个事务执行完才能推进位点——Seconds_Behind_Master 会飙升，但 Exec_Master_Log_Pos 几乎不动。解决关键不在调参，而在源头拆分 + 正确回放。
先确认是不是大事务卡住
别只看延迟数值。在从库执行 SHOW SLAVE STATUS\G，重点盯三处：
-
Slave_SQL_Running_State 显示
Waiting for dependent transaction to commit或长时间停在Reading event from the relay log -
Exec_Master_Log_Pos 长时间不变化，和
Read_Master_Log_Pos的差距持续拉大 - Seconds_Behind_Master 稳定上涨（比如每秒+1、+2），不是跳变
再查主库有没有活跃大事务：SELECT trx_id, trx_started, trx_rows_modified, SUBSTRING(trx_query, 1, 50) FROM information_schema.INNODB_TRX WHERE trx_rows_modified > 10000 AND trx_started <br>
有结果，基本就是它了。
主库端必须拆分，不能只靠从库优化
并行复制对单个大事务无效——它被当作一个原子单元串行回放。真正有效的动作在主库：
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
INSERT/UPDATE/DELETE 加 LIMIT 不等于拆事务：必须显式
BEGIN+COMMIT包裹每一批，否则仍是隐式小事务堆叠，binlog 更大、relay log 更快堆积 -
用主键或时间字段分段：比如
WHERE id BETWEEN ? AND ?或WHERE created_at > ? AND created_at ，避免 <code>OFFSET导致越跑越慢 -
每批控制在 5000–10000 行以内，单次执行不超过 2 秒；中间可加
SLEEP(0.1)缓冲压力 -
DDL 大操作必须用 pt-online-schema-change 或 gh-ost，原生
ALTER TABLE在从库仍要单线程执行，延迟直接等于主库耗时
检查并行复制是否真生效
开了 slave_parallel_workers > 0 不代表并行就跑起来了：
- slave_parallel_type 必须是 LOGICAL_CLOCK（5.7+）或 WRITESET（8.0+），设成 DATABASE 没用——大事务通常集中在单库单表
- 主库 binlog_format 必须为 ROW，STATEMENT 模式下函数、临时表等可能让拆分失效
- 查从库：
SELECT * FROM performance_schema.replication_applier_status_by_worker;看LAST_SEEN_TRANSACTION是否有多个非空值；全为空说明并行没跑起来
警惕“伪大事务”
代码里没写 BEGIN，但循环中反复 INSERT/UPDATE 又不 COMMIT，autocommit=1 时每句都是独立事务——看着小，实际因网络延迟、锁竞争、日志刷盘等，整体效果等同于大事务：
- ORM 批量操作（如 Django
bulk_create、MyBatisforeach）需显式指定batch_size=1000 - ETL 工具（DataX、Flink CDC）的
batchSize和maxFetchSize必须对齐，否则一次拉 10 万行再逐条发 INSERT，binlog 体积翻倍 - 定时脚本中漏写
COMMIT或异常未ROLLBACK，也会让事务悬停几十分钟
不复杂但容易忽略的是：大事务问题从来不是复制机制的缺陷，而是业务写法、开发习惯和运维监控共同作用的结果。
