最直接判断主从复制是否正常运行的方法是执行show slave status\g，确认slave_io_running和slave_sql_running均为yes，且seconds_behind_master为0或稳定在个位数。
怎么看主从复制是否真的在跑
最直接的办法就是进从库 MySQL 客户端，执行 SHOW SLAVE STATUS\G。别在 Linux shell 里敲这个命令——否则会报 bash: show: command not found。关键看三处：Slave_IO_Running 和 Slave_SQL_Running 都得是 Yes；Seconds_Behind_Master 要么是 0，要么稳定在个位数（比如 1~3 秒）。如果这个值持续上涨，或者变成 NULL，说明复制线程已经停了。
延迟飙升时该查哪几行日志
延迟不是凭感觉，得靠证据定位。先看从库错误日志：tail -f /var/log/mysql/error.log。常见线索包括：Last_IO_Error（IO 线程连不上主库、权限不对、binlog 文件被删）、Last_SQL_Error（SQL 线程执行某条语句失败，比如主库删了表但从库还留着触发器）。如果是 GTID 模式，还要比对 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否一致——不一致就说明有事件卡在 relay log 里没执行。
用 pt-table-checksum 校验数据是否真一致
SHOW SLAVE STATUS 只能告诉你“线程在跑”，不能保证“数据没丢”。真正校验一致性得靠工具：pt-table-checksum 是 Percona 提供的成熟方案。它会在主库上分块计算校验和，再让从库回传结果对比。运行命令类似：pt-table-checksum --host=master_host --user=user --password=pass --databases=test_db。注意：必须确保主从 binlog 格式一致（推荐 ROW），且从库开启 log_slave_updates（级联复制场景下尤其重要）。
监控告警不能只盯 Seconds_Behind_Master
单靠 Seconds_Behind_Master 做告警容易误报。比如大事务正在执行时，这个值会突增几十秒，但其实是正常现象；而一旦 SQL 线程卡死，它可能长期停留在某个非零值不动，反而漏掉故障。更稳妥的做法是组合判断：Slave_IO_Running = Yes + Slave_SQL_Running = Yes + Seconds_Behind_Master 。用 Prometheus + <a style="color:#f60; text-decoration:underline;" title="mysql" href="https://www.php.cn/zt/15713.html" target="_blank">mysql</a>d_exporter 采集这些指标，比写脚本轮询 <code>SHOW SLAVE STATUS 更可靠。另外，Relay_Log_Space 如果持续增长，说明中继日志堆积，往往预示 SQL 线程已滞后或阻塞，这个字段常被忽略。
