判断主从复制真实延迟需综合GTID比对、时间戳标记、Relay_Log_Space增长及Exec/Read_Log_Pos差值，而非仅依赖Seconds_Behind_Master；优化需拆分大事务、调优并行参数与IO刷盘策略，并谨慎处理DDL阻塞。
主从复制延迟怎么判断是否真实存在
延迟不等于 Seconds_Behind_Master 显示为 0。这个值在从库 SQL 线程空闲、IO 线程也跟得上时才准确；一旦 SQL 线程卡住（比如大事务回放中），它可能长时间停在某个值不动，甚至跳变。更可靠的方式是用 GTID 或时间戳比对：
- 在主库执行
SELECT @@gtid_executed;，再在从库查同字段，对比末尾的事务 ID 是否一致 - 或主库写入带
NOW()的标记行，从库查该行时间差 -
SHOW SLAVE STATUS\G中关注Exec_Master_Log_Pos和Read_Master_Log_Pos是否持续接近，若差值稳定增大，说明 SQL 线程跟不上
常见误判：网络抖动导致 IO 线程短暂断连，Seconds_Behind_Master 会先跳成 NULL，恢复后归 0，但这不代表没积压——要看 Relay_Log_Space 是否异常增长。
如何减少单个事务对复制的阻塞
MySQL 5.7+ 默认开启 slave_parallel_workers > 0，但仅靠并行回放不够，关键在事务粒度：
- 避免在主库执行超长事务（如
UPDATE ... WHERE扫描千万行），拆成小批量（每次LIMIT 1000+SLEEP(0.1)） - 关闭
innodb_lock_wait_timeout过短引发的死锁重试循环（重试会生成新事务，加剧从库压力） - 主库写 binlog 前加
SET SESSION binlog_format = 'ROW'，避免混合模式下函数/临时表导致的串行化回放 - 从库设置
slave_preserve_commit_order = ON（需slave_parallel_type = LOGICAL_CLOCK），否则并行回放可能破坏事务间依赖，反而触发重试或卡死
注意：即使开了并行，如果主库事务全是同一 database + 同一 table，MySQL 仍按库级分组，实际并行度为 1。
哪些配置项真正影响从库回放速度
优化不是调高 slave_parallel_workers 就完事。以下参数组合更关键：
-
innodb_flush_log_at_trx_commit = 2（从库可设，降低刷盘频率，但牺牲少量安全性） -
sync_binlog = 0（从库无需 binlog，关掉） -
innodb_buffer_pool_size必须足够大，否则回放时频繁读磁盘，SHOW ENGINE INNODB STATUS中看Buffer pool hit rate是否低于 99% -
slave_checkpoint_period缩短（如 2 秒），加快故障恢复时的位点定位，减少重启后追赶时间 - 禁用从库的
innodb_doublewrite（5.7+ 支持只读实例关闭，需确认业务允许）
别碰 slave_skip_errors 来“加速”——跳过错误只会让数据不一致更隐蔽。
DDL 操作为何总导致复制卡顿
ALTER TABLE 在主库执行时，整个语句作为一个大事务写入 binlog；从库必须等它完全执行完才能继续后续事件。尤其在 ALGORITHM=COPY 模式下：
- 主库生成临时表、拷贝数据、rename，binlog 记录的是最终 rename，但从库要完整重放过程
- 解决方法：主库用
ALGORITHM=INPLACE（如ADD COLUMN）或pt-online-schema-change工具分片改 - 从库提前加
innodb_read_only = OFF（默认），否则 DDL 会直接报错中断复制 - 若已卡住，不要 kill
ALTER线程——从库 SQL 线程会进入不可恢复状态；应先 stop slave，手动在从库执行相同 DDL（确保数据一致前提下），再 start slave
DDL 的延迟往往不是“慢”，而是“原子性阻塞”，这点和普通 DML 完全不同。
