应拆分大事务并优化复制配置：用pt-osc替代ALTER，分批UPDATE加SLEEP限流，确保WHERE字段有索引；ROW模式下启用binlog_row_image=MINIMAL、调小max_binlog_size；从库设slave_parallel_type=LOGICAL_CLOCK、slave_parallel_workers≥4，并主库开启WRITESET依赖追踪。
大事务导致从库延迟严重怎么办
MySQL 主从复制中，一个 UPDATE 或 DELETE 涉及几百万行，从库可能卡住十几分钟——这不是网络或硬件问题，是事务在 binlog 里被当作单个原子事件重放，从库只能串行执行。尤其当主库用 ROW 格式记录变更时，每行变更都写进 binlog，从库得一条条 apply。
实操建议：
- 监控
Seconds_Behind_Master突增 +SHOW PROCESSLIST中看到Reading event from the relay log长时间不结束，基本可定位为大事务回放瓶颈 - 避免在业务高峰期执行
ALTER TABLE ... ADD INDEX或全表UPDATE，这类操作默认生成超长事务 - 用
pt-osc（Percona Toolkit）替代直接ALTER，它自动分块、带限流，不锁表也不造大事务
怎么安全拆分一个 500 万行的 UPDATE
直接 UPDATE t SET status=1 WHERE create_time 会锁全表、打满 binlog、拖垮从库。必须切片，但切片方式不对反而更糟——比如按主键范围切，若主键不连续或有空洞，可能漏数据或重复更新。
实操建议：
- 优先按自增主键分批，用
WHERE id BETWEEN ? AND ?，每次控制在 5k–10k 行（具体看单行大小和 QPS 压力） - 加
LIMIT但不用OFFSET：改用游标式推进，例如WHERE id > last_id ORDER BY id LIMIT 10000，避免越往后越慢 - 每批后主动
SLEEP(0.1)（毫秒级），降低主库压力和从库追平难度；不要依赖从库自动“匀速”，它不会自己限流 - 确保 WHERE 条件字段有索引，否则每批都会全表扫——
EXPLAIN必须看到type=range或更好
binlog_format=ROW 下大事务更危险的原因
很多人以为 ROW 格式更安全就无脑开，其实它会让大事务对复制的冲击翻倍：一条 UPDATE 影响 100 万行，在 ROW 模式下会生成约 100 万条 binlog event；而 STATEMENT 只记一条 SQL（但有安全风险）。从库重放时，ROW 是逐行解析+应用，CPU 和磁盘 IO 压力远高于 STATEMENT 的简单执行。
实操建议：
- 不因兼容性或审计需求盲目设
binlog_format=ROW，确认业务真需要行级变更日志再启用 - 若必须用
ROW，务必配合binlog_row_image=MINIMAL（MySQL 5.6+），避免记录未修改列，减小 binlog 体积 -
max_binlog_size默认 1G 不够用——大事务可能撑爆单个 binlog 文件，建议调小到 256M，让轮转更频繁，也便于定位问题段
从库并行复制没起作用？检查这三项配置
MySQL 5.7+ 支持基于库（DATABASE）或基于组提交（LOGICAL_CLOCK）的从库并行复制，但默认不开启或配置不当等于没开。常见现象是 Slave_SQL_Running_State 显示 Reading event from the relay log，始终只有一个线程在干活。
实操建议：
- 确认
slave_parallel_type=LOGICAL_CLOCK（不是DATABASE），后者在单库场景完全无效 -
slave_parallel_workers至少设为 4（别信“CPU 核数”那种建议，实际 4–8 更稳），并重启从库生效 - 主库必须开启
binlog_transaction_dependency_tracking=WRITESET（MySQL 8.0.19+）或至少COMMIT_ORDER，否则从库无法判断事务间是否可并行
真正麻烦的是跨事务的逻辑依赖：比如事务 A 插入用户，事务 B 立即更新该用户，即使开了并行，B 也必须等 A 完——这种隐式依赖没法靠配置解决，只能靠业务层控制写入节奏或拆分粒度。
