slave_parallel_workers建议从4起步，逐步调至8或12，并须配合slave_parallel_type=logical_clock、binlog_format=row、slave_preserve_commit_order=on及relay_log_recovery=on等参数才能有效降低主从延迟。
主从延迟大时，slave_parallel_workers 设多少才有效？
并行复制不是开得越多越好。MySQL 5.7+ 的基于组提交的并行复制（slave_parallel_type=LOGICAL_CLOCK）依赖于主库的 binlog_group_commit_sync_delay 和事务分组质量。如果主库写入本身是单线程密集小事务（比如频繁 UPDATE 单行），从库即使设了 slave_parallel_workers=16，实际并发度可能还是 1～2。
-
slave_parallel_workers建议从4起步，逐步加到8或12，观察SHOW SLAVE STATUS\G中的Seconds_Behind_Master和Slave_SQL_Running_State（是否常驻 “Reading event from the relay log”） - 必须同时设
slave_parallel_type=LOGICAL_CLOCK，默认的DATABASE类型在单库多表场景下几乎不并行 - 如果主库
binlog_format=STATEMENT，逻辑时钟机制失效，并行复制退化为串行——务必确认是ROW
slave_preserve_commit_order=ON 是必须开的吗？
开。否则即使开了并行复制，从库提交顺序错乱会导致主从数据不一致，尤其在有外键、触发器或应用依赖事务先后关系时。
-
slave_preserve_commit_order=ON强制 SQL 线程按主库的提交顺序落地变更，是并行复制安全的前提 - 它会轻微增加从库延迟（因为要等“同组”所有 worker 完成再统一提交），但换来的是数据一致性保障
- 这个参数只在
slave_parallel_type=LOGICAL_CLOCK下生效；设为DATABASE时无效
网络延迟高时，relay_log_recovery 和 master_info_repository 怎么配？
高延迟网络下，IO 线程容易断连重试，relay log 文件可能损坏或不完整。此时若没启用自动恢复机制，从库重启后可能跳过部分日志，直接导致数据丢失。
- 必须开启
relay_log_recovery=ON：每次启动从库时自动丢弃未校验完的 relay log，重新从 master 拉取 -
master_info_repository=TABLE和relay_log_info_repository=TABLE必须同时设为TABLE（而非FILE），否则relay_log_recovery不生效 - 配合
sync_relay_log=1（每次写 relay log 都刷盘），避免断电丢日志；但会降低 IO 线程吞吐，需权衡
为什么调了参数，Seconds_Behind_Master 还是忽高忽低？
这不是参数没起作用，而是高延迟网络下典型的“假性延迟”。真实瓶颈可能不在复制本身，而在网络抖动引发的重传、TCP 超时、或从库磁盘 IOPS 不足。
- 先用
tcpdump或pt-heartbeat确认是复制延迟，还是网络 RTT 波动导致Seconds_Behind_Master计算失真（它依赖 SQL 线程时间戳与系统时间差） - 检查从库
iotop -a，看mysqld是否卡在 disk write；如果是，innodb_flush_log_at_trx_commit=2和sync_binlog=0可缓解（但牺牲一定安全性） - 避免在从库执行大查询或
SELECT ... FOR UPDATE，这类操作会阻塞 SQL 线程，让延迟数字瞬间飙升，和复制无关
主从延迟诊断里最容易被忽略的，是把网络层抖动误判为复制参数问题。先确认链路稳定性，再调参。
