主从延迟高需分四步排查修复：先确认真实延迟（查io/sql线程状态、gtid差异、pt-heartbeat），再定位卡点（io拉取、sql回放、锁等待），接着针对性处理大事务、硬件不足、ddl阻塞等问题，最后开启并行复制并加强监控。
主从延迟高不是单一问题，而是复制链路上多个环节协同失衡的结果。核心思路是先确认是否真延迟、再定位卡点在哪、最后针对性修复，不能只盯着 Seconds_Behind_Master 数值。
第一步：确认真实延迟，别被假象骗了
执行 SHOW SLAVE STATUS\G 后，重点看三个字段：
-
Slave_IO_Running 和 Slave_SQL_Running 必须都是
Yes；只要有一个是No，说明同步已中断，延迟值失去意义 -
Seconds_Behind_Master > 0 是延迟信号，但为
NULL或长期不变（比如卡在 37265 秒）往往意味着 SQL 线程被阻塞，而非单纯慢 - 对比 Retrieved_Gtid_Set 和 Executed_Gtid_Set：如果前者持续增长、后者停滞不动，基本可断定是 SQL 线程卡在某个事务上
更可靠的方式是部署 pt-heartbeat，它通过写入时间戳表并从从库读取差值，反映真实数据落盘延迟，不受大事务或网络抖动干扰。
第二步：快速定位卡点位置
复制链路分三段：主库 dump → 网络传输 → 从库 relay + 回放。按顺序排查：
-
IO 线程是否跟得上？ 查看
Relay_Log_Space是否持续增大；若增大很快，说明 binlog 拉取没问题，问题在从库回放侧 -
SQL 线程是否忙碌？ 执行
SHOW PROCESSLIST，找状态为Reading event from the relay log或executing且运行时间很长的线程；同时查INFORMATION_SCHEMA.INNODB_TRX，看是否有超长事务正在执行 -
有没有锁等待？ 特别注意 DDL 操作（如
ALTER TABLE）会触发元数据锁（MDL），导致后续所有事务排队；检查performance_schema.metadata_locks表可验证
第三步：常见卡点与对应修复动作
根据高频根因，直接对应处理：
-
大事务压垮 SQL 线程：主库批量导入、归档删除等操作未拆分。修复方式：在业务低峰期重跑，并把单事务控制在 1 万行以内；从库启用
slave_preserve_commit_order=ON配合并行复制，避免退化为串行 -
从库硬件拖后腿：CPU 核数少于主库、磁盘仍是 HDD、
innodb_buffer_pool_size不足总内存 70%。修复方式：从库配置至少不弱于主库；强制使用 SSD；调大 buffer pool 并重启 -
DDL 导致元数据锁阻塞：主库执行
ALTER后，从库 SQL 线程卡住。修复方式：改用ALGORITHM=INPLACE的 Online DDL；或提前在从库执行相同 DDL（确保 GTID 不冲突） -
ROW 格式 + 分区表 + 无主键/二级索引扫描：这类组合会让从库回放极慢。修复方式：给表补全主键；避免在存储过程中执行条件复杂的 DELETE；必要时临时切回
STATEMENT格式（需评估安全性）
第四步：稳态优化，防止反复复发
修复完当前问题后，要做两件事防复发：
-
开启多线程复制：MySQL 5.7+ 设置
slave_parallel_workers = 8（建议设为 CPU 核数的 75%），并确保binlog_transaction_dependency_tracking = WRITESET，提升并行粒度 -
加监控告警：对
Seconds_Behind_Master > 30、Relay_Log_Space > 2G、SQL 线程状态异常等设置分钟级告警，别等用户投诉才响应
不复杂但容易忽略
