大事务导致MySQL主从复制延迟飙升，因SQL线程串行回放binlog，单个长事务阻塞后续所有事务；即便启用并行复制，若未按库/表粒度拆分事务仍无效。
大事务为什么会让MySQL主从复制延迟飙升
因为MySQL默认的单线程SQL线程（sql_thread）必须串行回放主库的binlog事件，一个执行20分钟的UPDATE或DELETE事务，会把后面所有事务全部堵住——从库延迟直接涨到小时级，监控报警响个不停。
这不是网络或IO瓶颈，是架构层面的串行化枷锁。哪怕开了并行复制（slave_parallel_workers > 0），只要事务没打散、没按库/表粒度切分，照样无效。
- 常见诱因：
DELETE FROM orders WHERE created_at （千万级扫描）、全表<code>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 < '2023-01-01' AND id <= 1000000 ORDER BY id LIMIT 1000; COMMIT;
多线程复制不是开个参数就完事——必须配对设置
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批，每批都全表扫描，延迟更严重
