SHOW SLAVE STATUS报错或返回NULL说明用户缺REPLICATION CLIENT权限；Seconds_Behind_Master为NULL表示SQL线程未运行，0不代表实时同步，负数属正常抖动；需重点关注Slave_IO_Running、Slave_SQL_Running、Seconds_Behind_Master、Relay_Log_Space及GTID集合一致性。
show slave status 返回了 NULL 或报错 ERROR 1227
说明当前连接的用户没有 SUPER 或 REPLICATION CLIENT 权限，MySQL 8.0+ 默认只允许高权限用户执行该命令。
- 用
SHOW GRANTS FOR CURRENT_USER;确认权限，缺权限就让 DBA 执行：GRANT REPLICATION CLIENT ON *.* TO 'your_user'@'%'; - 注意：MySQL 8.0 不再隐式授予
SUPER，即使有ALL PRIVILEGES也不等于能查主从状态 - 如果连库时指定了
--binary-as-hex或用了某些代理（如 ProxySQL），也可能触发异常返回，建议直连 MySQL 实例排查
Seconds_Behind_Master 显示 NULL、0 或负数
这个字段不是“实时延迟”，而是 IO 线程与 SQL 线程协作下的估算值，含义容易误读。
-
NULL：表示 SQL 线程没在运行（Slave_SQL_Running: No），或主库没开启 binlog（极少见） -
0：不等于完全同步，只代表当前 relay log 已全部执行完；若主库正大量写入，新事件还没拉过来，实际仍有延迟 - 负数（如
-1）：常见于 MySQL 5.7+ 启用了slave_parallel_workers > 0且使用逻辑时钟（slave_preserve_commit_order=ON），属于内部计时器抖动，只要Seconds_Behind_Master能快速回到 0 就不用干预
关键字段速查：哪些必须盯住，哪些可忽略
别被 30+ 字段吓住，生产环境只需盯紧 5 个：
-
Slave_IO_Running和Slave_SQL_Running：必须都是Yes，任一为No表示复制中断 -
Seconds_Behind_Master：趋势比瞬时值重要，持续上升需查原因（网络？大事务？从库负载高？） -
Relay_Log_Space：持续增长且不下降，大概率是 SQL 线程卡住（比如遇到 DDL 锁、唯一键冲突） -
Retrieved_Gtid_Set与Executed_Gtid_Set：GTID 模式下二者应严格相等，不等说明有事务没执行（常见于跳过事务后未清理gtid_executed）
用 SELECT + performance_schema 查替代方案
当 SHOW SLAVE STATUS 因权限或锁表不可用时，可用系统表兜底，但要注意兼容性。
- MySQL 8.0+ 可查：
SELECT * FROM performance_schema.replication_connection_status;（对应 IO 线程）和replication_applier_status_by_coordinator（对应 SQL 协调线程） - 这些表字段名不同，例如原
Seconds_Behind_Master对应APPLIED_DELAY，且默认不显示延迟数值，得配合replication_applier_status_by_worker计算 - MySQL 5.7 不支持上述表，只能靠
SHOW PROCESSLIST看是否有System lock或Waiting for master to send event这类线索
主从状态里最麻烦的不是字段看不懂，而是所有指标都“看起来正常”时，业务却突然报查询结果不一致——这时候往往要翻 relay-log.info 文件或检查 gtid_purged 是否被意外重置。
