准确判断主从延迟应比对binlog位置（Read_Master_Log_Pos与Exec_Master_Log_Pos）或GTID集合（gtid_executed、Retrieved_Gtid_Set、Executed_Gtid_Set），而非依赖Seconds_Behind_Master；常见错误1032、1062、2003需结合Last_SQL_Errno/Last_SQL_Error定位处理。
查看主从延迟的准确方法
仅看 Seconds_Behind_Master 不可靠，尤其在从库 IO 线程异常或 relay log 未更新时，该值可能固定为 NULL 或 0，但实际已落后。真正有效的判断方式是比对主从的 binlog 位置和 GTID 集合。
- 在从库执行
SHOW SLAVE STATUS\G，重点关注Read_Master_Log_Pos（IO 线程读到的位置）和Exec_Master_Log_Pos（SQL 线程执行到的位置），两者差值过大说明 SQL 线程积压 - 若启用 GTID，对比主库的
SELECT @@global.gtid_executed;和从库的Retrieved_Gtid_Set、Executed_Gtid_Set，三者不一致即存在延迟或断点 - 避免依赖
pt-heartbeat的单点时间戳——它只反映心跳表更新延迟，无法覆盖 DDL、大事务或复制过滤场景
常见复制错误类型与快速定位命令
MySQL 复制中断时，Slave_SQL_Running: No 是表象，关键要看 Last_SQL_Errno 和 Last_SQL_Error 字段。不同错误需不同处理路径，不能一概跳过。
-
Last_SQL_Errno: 1032：从库找不到要更新/删除的行 → 检查是否主库有binlog_format = STATEMENT+ 非确定性函数，或从库被误写入；用mysqlbinlog --base64-output=DECODE-ROWS -v解析对应 binlog 事件确认操作内容 -
Last_SQL_Errno: 1062：唯一键冲突 → 常见于多源复制、手动插入或自增列未设auto_increment_offset/auto_increment_increment；先确认冲突记录是否应存在，再决定是跳过（SET GLOBAL sql_slave_skip_counter = 1）还是修复数据 -
Last_SQL_Errno: 2003 / 2013：网络类错误 → 查Slave_IO_Running状态，检查主库max_connections是否耗尽、防火墙是否拦截3306、从库master_host配置是否为域名且 DNS 不稳定
修复延迟积压的实操策略
当 Exec_Master_Log_Pos 落后数 GB 时，盲目重启 SQL 线程或调大 slave_parallel_workers 可能加剧问题。优先确认积压是否由单一大事务引起。
- 用
SHOW PROCESSLIST在从库中找状态为Reading event from the relay log或长时间Updating的线程，结合information_schema.INNODB_TRX查事务持续时间 - 若确认是单个大事务（如
DELETE FROM huge_table WHERE create_time ），不要 kill，而是等其完成；否则可能触发回滚并锁表更久 - 对持续写入型延迟，可临时启用并行复制：
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 4;，但需确保主库binlog_transaction_dependency_tracking为WRITESET或WRITESET_SESSION - 禁用
innodb_flush_log_at_trx_commit = 2和sync_binlog = 0可提升从库回放速度，但会牺牲崩溃安全性，仅限临时应急
GTID 复制下跳过错误的正确姿势
开启 GTID 后，不能再用 sql_slave_skip_counter，必须用 gtid_next 注入空事务。操作不当会导致 GTID 集合错乱，后续无法重建复制关系。
- 先停复制：
STOP SLAVE; - 查当前报错事务的 GTID：
SELECT @@global.gtid_executed;和SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set - 假设出错 GTID 是
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1001，执行：SET GTID_NEXT='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaa1:1001'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC';
- 再
START SLAVE;，观察Executed_Gtid_Set是否向前推进 - 注意：跳过的 GTID 必须存在于
Retrieved_Gtid_Set中，否则会报错Could not execute because of problems with GTID consistency
