seconds_behind_master高不代表真延迟，但持续大于30秒说明复制失控；slave_parallel_workers无效主因是slave_parallel_type仍为database（单库写入时强制串行），须切logical_clock并重启sql线程，且主库需启用gtid和组提交。
Seconds_Behind_Master 高不代表真延迟，但持续大于 30 秒基本说明复制链路已失控，必须立刻干预。
为什么 slave_parallel_workers 设了还是不并行？
并行复制不是“开了线程数就自动跑起来”。关键看 slave_parallel_type 策略是否匹配业务写入模式：
-
slave_parallel_type = DATABASE（MySQL 5.6 默认）：只对跨库 DML 并行；如果所有表都在db1，哪怕设了 16 个 worker，SQL 线程仍串行回放 -
slave_parallel_type = LOGICAL_CLOCK（MySQL 5.7+ 推荐）：依赖主库binlog_group_commit_sync_delay+ GTID + group commit 打包事务，才能让同库内事务并行 - 切换后必须重启 SQL 线程：
STOP SLAVE SQL_THREAD; START SLAVE SQL_THREAD;，仅改变量不生效 - 检查主库是否真有 group commit：执行
SHOW MASTER STATUS后观察Executed_Gtid_Set是否连续、有无 gap；再查SELECT * FROM performance_schema.replication_applier_status_by_worker;看各 worker 的LAST_SEEN_TRANSACTION是否真正分散
Seconds_Behind_Master 卡在 0 但实际已延迟？
这个值只反映 relay log 最后一条事务的提交时间戳与当前系统时间差，极易误判：
- 正在执行一个大事务（比如
UPDATE big_table SET status=1 WHERE create_time ），<code>Seconds_Behind_Master会卡在 0，但Exec_Master_Log_Pos几乎不动 - IO 线程拉取慢但还没积压到 relay log 文件层面（如网络抖动导致
Read_Master_Log_Pos停滞），此时Relay_Log_Space不涨，Seconds_Behind_Master也难体现 - 真实延迟要看三组差值：
Read_Master_Log_Pos - Exec_Master_Log_Pos（未执行的 binlog 位点差）、Relay_Log_Space是否持续增长、以及replication_applier_status_by_worker中各 worker 的LAST_APPLIED_TRANSACTION时间戳
网络和磁盘 IO 是隐藏瓶颈
很多团队只调参数，却忽略底层资源是否跟得上：
-
net_read_timeout/net_write_timeout调小能加快断连重试，但解决不了吞吐问题；真正要测的是主从间实际带宽：用iperf -c 主库IP -t 60看能否跑满业务峰值流量（例如主库每秒写入 20MB binlog，网络必须稳定 ≥25MB/s） - 从库磁盘 IO 是硬门槛：
innodb_flush_log_at_trx_commit = 2可显著降低刷盘压力，但需接受极小概率 crash loss；SSD 必须是 NVMe 级别，SATA SSD 在高并发回放下 IOPS 容易打满 - 别忽略
relay_log_space_limit：设得太小会导致频繁 rotate relay log，引发额外 IO 和锁等待；建议设为 4G～8G，配合监控Relay_Log_Space
大事务和 DDL 是延迟放大器
它们本身不产生大量日志，但会阻塞整个复制流水线：
- 主库一个
DELETE FROM logs WHERE ts （影响 500 万行），从库 SQL 线程会卡死这一个事务，期间所有后续事务排队等待 - DDL 操作（如
ALTER TABLE）在从库需获取 MDL 锁，若此时从库正执行长查询，就会形成锁等待链；SHOW PROCESSLIST中能看到Waiting for table metadata lock - 解决方案不是“不让做”，而是拆解：
DELETE改成LIMIT 10000循环 +COMMIT；DDL 优先用pt-online-schema-change或 MySQL 8.0+ 的ALGORITHM=INSTANT
真正卡住复制的，往往不是单个配置项，而是多个环节叠加——比如主库 group commit 关闭 + 从库单线程 + SATA SSD + 大事务，四个条件凑齐，延迟想不高都难。盯住 Read_Master_Log_Pos 和 Exec_Master_Log_Pos 的移动节奏，比盯着 Seconds_Behind_Master 有用得多。
