大事务导致MySQL主从复制延迟飙升，因SQL线程串行回放binlog，单个长事务阻塞后续所有事务；即便启用并行复制，若未按库/表粒度拆分事务仍无效。

大事务为什么会让MySQL主从复制延迟飙升

因为MySQL默认的单线程SQL线程（sql_thread）必须串行回放主库的binlog事件，一个执行20分钟的UPDATE或DELETE事务，会把后面所有事务全部堵住——从库延迟直接涨到小时级，监控报警响个不停。

这不是网络或IO瓶颈，是架构层面的串行化枷锁。哪怕开了并行复制（slave_parallel_workers > 0），只要事务没打散、没按库/表粒度切分，照样无效。

• 常见诱因：DELETE FROM orders WHERE created_at （千万级扫描）、全表UPDATE、未加LIMIT的批量清理
• 识别方式：查SHOW SLAVE STATUS\G，重点关注Seconds_Behind_Master持续上涨 + Exec_Master_Log_Pos几乎不动
• 关键事实：binlog格式为ROW时，大事务仍以单个GTID或binlog position为单位提交，无法被并行线程拆解

怎么安全拆分一个正在运行的大事务

不能直接在主库上改SQL加LIMIT——可能跳过数据或重复执行。必须保证语义等价、幂等、可中断续跑。

Mysql Skill 1.0.0 (3)

MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。

下载

• 用自增主键或时间字段分片：WHERE id BETWEEN 1000000 AND 1000100，每次处理100条，循环推进
• 加ORDER BY id LIMIT 100防止幻读干扰；每次执行后记录最大id到临时表或文件，避免漏处理
• 务必关闭自动提交：SET autocommit = 0，手动COMMIT每批次，否则每个LIMIT子句仍生成独立事务，binlog膨胀更严重
• 示例片段：

  START TRANSACTION;
  DELETE FROM logs WHERE ts 

多线程复制不是开个参数就完事——必须配对设置

slave_parallel_workers = 4单独设置毫无意义。MySQL 5.7+ 的并行复制依赖slave_parallel_type和事务分组策略，不匹配等于白开。

• 优先选slave_parallel_type = LOGICAL_CLOCK（基于binlog_group_commit），但要求主库binlog_order_commits = ON（默认值，别关）
• 如果业务按库隔离强，可用slave_parallel_type = DATABASE，此时每个库的事务可并行，但跨库事务仍串行
• 必须确认主库binlog_format = ROW且transaction_write_set_extraction = XXHASH64（8.0+支持write-set并行，比logical clock更细粒度）
• 检查从库是否真正启用：SELECT * FROM performance_schema.replication_applier_status_by_worker;，看WORKER_ID是否有多个非空记录

最容易被忽略的两个坑

一是大事务期间主库binlog_cache_size不足，导致频繁刷盘、性能抖动，间接拖慢复制节奏；二是从库relay_log_recovery = ON未开启，主从切换后relay log损坏，恢复失败。

• binlog_cache_size建议调大到4M以上（配合max_binlog_cache_size），尤其当单事务涉及上万行变更时
• 从库务必确认relay_log_recovery = ON，避免意外宕机后relay log不完整，START SLAVE报错Could not parse relay log event entry
• 拆分脚本上线前，在从库只读模式下先用EXPLAIN验证分片条件是否走索引——否则拆成100批，每批都全表扫描，延迟更严重