Seconds_Behind_Master不可靠，需结合Slave_IO_Running、Slave_SQL_Running状态及NULL判断；Go中须用sql.NullInt64接收，配置超时与只读账号；主从时钟偏差致其失真，应辅以GTID和心跳表打点验证。
怎么用 SHOW SLAVE STATUS 拿到延迟值
MySQL 主从延迟的核心指标是 Seconds_Behind_Master，但它不是永远可靠——从库 SQL 线程停止、IO 线程断开、或者主库没新 binlog 时，这个值可能显示 NULL 或 0，实际却已脱节。
Go 程序里不能只查一次就完事，得组合判断：
- 先执行
SHOW SLAVE STATUS，解析Seconds_Behind_Master字段； - 同时检查
Slave_IO_Running和Slave_SQL_Running是否都为Yes； - 若任一为
No，延迟值失效，应标记为「异常」而非「0 秒」； - 若
Seconds_Behind_Master是NULL，常见于从库刚启动或 relay log 清空后，也需单独告警。
用 mysql 驱动执行查询要注意什么
别用 database/sql 的 QueryRow 直接 Scan 到 int —— Seconds_Behind_Master 在 MySQL 返回结果里是 sql.NullInt64 类型（因为可为空），硬转 int64 会 panic。
正确做法是声明接收变量为 sql.NullInt64，再判断 Valid：
立即学习“go语言免费学习笔记（深入）”；
var delay sql.NullInt64
err := row.Scan(&delay)
if err != nil { /* handle */ }
if !delay.Valid {
// 延迟值不可用，比如 NULL 或连接失败
}另外，连接从库时务必用只读账号，并限制超时：timeout=3s&readTimeout=3s&writeTimeout=3s，避免监控探针卡住整个健康检查流程。
为什么不能只依赖 Seconds_Behind_Master
这个字段本质是「主库当前时间」减去「从库已执行的最后一条事件的时间戳」，前提是主从时钟一致。一旦主库和从库系统时间偏差 >1 秒，数值就失真；NTP 同步滞后、虚拟机休眠、云厂商宿主机时间跳变都会导致误报。
更稳的方式是用半同步 + GTID + 时间戳打点：
- 在主库写入关键业务数据前，插入一条带
NOW(6)的心跳表记录； - 从库定时查这条记录的写入时间和本地当前时间差，作为真实延迟；
- 配合
gtid_executed对比，能发现 GTID 跳过、事务被过滤等Seconds_Behind_Master完全无法反映的问题。
如何让 Go 监控不拖慢主服务
延迟检查不是越频越好。每秒连一次从库做 SHOW SLAVE STATUS，容易触发 MySQL 的连接数限制或被防火墙限速。
合理策略是：
- 基础探测间隔设为 5–15 秒，用独立 goroutine 轮询，不走主服务 HTTP handler；
- 把结果缓存到内存变量（如
atomic.Value），HTTP 接口 /metrics 只读不查库； - 遇到连续 3 次超时或
Slave_IO_Running=No，才触发告警并尝试重连； - 避免在
http.HandlerFunc里实时查库——用户请求不该为监控买单。
真实环境里，最常被忽略的是权限和网络：MySQL 从库账号没授 REPLICATION CLIENT 权限，或者 k8s Pod 网络策略默认阻断了从库的 3306 出向连接，查不到状态不是代码问题，是部署漏了。
