Seconds_Behind_Master不能单独作为延迟判断依据，必须结合Slave_IO_Running、Slave_SQL_Running及GTID集合（Retrieved_Gtid_Set与Executed_Gtid_Set）综合判断；任一线程为No时该值失真，NULL或0均不表示正常同步。
看 Seconds_Behind_Master 不能只盯一个数字
这个字段常被当成“主从延迟多少秒”的直接答案，但实际它只在 SQL 线程正常运行时才有意义。如果 SQL_Running 是 No，或者 IO_Running 是 No，Seconds_Behind_Master 就会显示 NULL 或 0，完全失真。
真正要看的是三者联动：
-
Slave_IO_Running: Yes—— 表示 IO 线程连得上主库、能拉取 binlog；要是No，先查Last_IO_Error -
Slave_SQL_Running: Yes—— 表示 SQL 线程能正常回放 relay log；要是No，重点看Last_SQL_Error -
Seconds_Behind_Master: NULL且两个线程都是Yes？说明 SQL 线程刚启停过，或主库当前没新事件，不一定是异常
Last_IO_Error 和 Last_SQL_Error 必须逐字读
这两个字段是排障第一入口，不是扫一眼“连接失败”就去重启复制。MySQL 的错误信息里往往藏着关键线索：
-
Last_IO_Error: error connecting to master 'repl@10.0.1.5:3306'—— 检查网络、防火墙、主库是否允许该账号从该 IP 连接（SHOW GRANTS FOR 'repl'@'%'） -
Last_SQL_Error: Duplicate entry '12345' for key 'PRIMARY'—— 典型的主从写冲突，可能是从库被误写，或 GTID 模式下跳过事务不当 -
Last_SQL_Error: Cannot execute the current event group—— 常见于开启binlog_format=STATEMENT时执行了非确定性函数（如NOW()、UUID()），建议切到ROW
对比 Master_Log_File 和 Relay_Master_Log_File 判断数据一致性
这两个文件名不一致，说明 SQL 线程还没执行完当前 relay log 中的全部事件，属于正常追赶状态；但如果长期卡在同一个 Relay_Master_Log_File 且 Exec_Master_Log_Pos 不动，就要怀疑是不是卡在某个事务里了。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
更可靠的做法是比对主从的位点是否“逻辑对齐”：
- 在主库执行：
SHOW MASTER STATUS，记下File和Position - 在从库执行：
SHOW SLAVE STATUS\G，看Master_Log_File == Relay_Master_Log_File且Read_Master_Log_Pos == Exec_Master_Log_Pos - 全相等 ≠ 数据完全一致（比如主库有未提交事务），但不等一定有问题
GTID 模式下必须看 Retrieved_Gtid_Set 和 Executed_Gtid_Set
启用 GTID 后，Seconds_Behind_Master 更不可靠，因为并行复制和 gap 可能导致延迟计算偏差。真正反映同步进度的是两个 GTID 集合：
-
Retrieved_Gtid_Set：已拉到 relay log 里的事务 ID 集合 -
Executed_Gtid_Set：已执行完成的事务 ID 集合 - 如果前者包含后者，差集就是“已拉未执行”的事务；若差集为空，说明 IO 和 SQL 都追平了（注意：不保证无错误，只是位点齐）
- 遇到
ERROR 1236 (HY000)类报错，大概率是 GTID set 冲突，需用SET GLOBAL gtid_purged = '...'手动修复，操作前务必确认 purged 范围
复制健康不是单点判断，而是多个字段交叉验证的结果。最容易被忽略的是：即使所有状态都是 Yes，只要 Last_SQL_Error 曾出现过非空值，就说明复制链路历史上断裂过——而 MySQL 不会自动告警这类“已恢复但曾失败”的情况。
