Seconds_Behind_Master 不可靠，仅表示 SQL 线程追上 relay log 末尾，不能反映数据一致或事务丢失；需结合 Slave_IO_Running、Slave_SQL_Running、GTID/position 对比、错误码及 pt-table-checksum 校验综合判断。
怎么看 Seconds_Behind_Master 是否真的可靠
很多人只看 Seconds_Behind_Master 是不是 0，就认为主从正常——这是最大误区。这个值为 0 只代表 SQL 线程追上了 relay log 的最后一条，不代表数据一致，也不代表没丢事务。
真正要确认健康，得结合多个指标一起看：
-
Slave_IO_Running和Slave_SQL_Running必须都是Yes -
Seconds_Behind_Master长期非 0（比如持续 > 60 秒），要查SHOW PROCESSLIST里 SQL 线程是否卡在某个慢查询或锁等待上 - 如果
Seconds_Behind_Master是NULL，说明 IO 线程没连上主库，或主库 binlog 被删了（常见于expire_logs_days设置过小） - 注意：在 GTID 模式下，
Seconds_Behind_Master在从库重启后可能短暂显示NULL，等 IO 线程重连并拉取新事件后才恢复
用 SHOW SLAVE STATUS\G 查哪些字段不能忽略
执行这条命令后，重点盯住这几个字段，它们比 Seconds_Behind_Master 更反映底层状态：
-
Master_Host和Master_Port：确认连的是预期的主库，不是误切到其他实例 -
Relay_Master_Log_File和Exec_Master_Log_Pos：组合起来表示“当前已执行到主库哪个 binlog 文件和位置”，可与主库的SHOW MASTER STATUS对比是否滞后 -
Retrieved_Gtid_Set和Executed_Gtid_Set（GTID 模式下）：前者是已拉到 relay log 的事务集合，后者是已执行的；两者不等就说明 SQL 线程没跟上，哪怕Seconds_Behind_Master=0 -
Last_IO_Errno/Last_SQL_Errno：非 0 就代表出错了，必须立刻看Last_IO_Error或Last_SQL_Error具体内容
为什么 pt-table-checksum 是唯一能验证数据一致性的工具
网络延迟、重复写入、SQL 过滤规则、字符集差异……这些都可能导致主从“看起来在跑”，但数据早已不一致。SHOW SLAVE STATUS 完全无法发现这类问题。
pt-table-checksum 是 Percona Toolkit 中专为这事设计的工具，原理是在主库分块计算校验和，并通过复制机制把校验语句传到从库执行，再对比结果：
- 必须在主库上运行，且账号要有
REPLICATION CLIENT+PROCESS+SELECT权限 - 默认跳过系统库和视图，可通过
--databases指定业务库 - 若从库报错
1062 Duplicate entry或1032 Can't find record，说明行级不一致，要用pt-table-sync修复 - 不要在业务高峰跑全库校验，加
--chunk-size和--sleep控制压力
监控脚本里最容易漏掉的三个检查点
自动化检查脚本常只做 SHOW SLAVE STATUS 解析，但以下三点不显式判断，等于白监控：
- 检查
Seconds_Behind_Master是否为NULL：很多脚本用整数比较，遇到NULL直接报错或跳过，导致故障沉默 - 检查
Slave_SQL_Running_State是否卡在Waiting for dependent transaction to commit（MGR 或并行复制场景），这不算错误状态，但实际已停滞 - 检查主库 binlog 是否被清理：在从库执行
SELECT MASTER_POS_WAIT('<code>Relay_Master_Log_File',Exec_Master_Log_Pos, 1)，返回-1就说明主库上对应 binlog 已不存在，复制不可逆中断
复制健康不是单点判断，是 IO 连通性、SQL 执行进度、GTID/position 追踪、数据一致性四层叠加验证。少一层，就可能在线上安静地腐烂一周才暴露。
