Seconds_Behind_Master 为 NULL 或突增，先看这两个线程是否活着
执行
SHOW SLAVE STATUS\G后，如果
Seconds_Behind_Master是
NULL，基本可以断定复制已中断，不是“慢”，而是“停了”。重点盯住
Slave_IO_Running和
Slave_SQL_Running这两个字段——只要有一个是
No，复制链路就断了。
IO_Running=No：通常是网络不通、主库权限不对（比如
replication slave权限没给）、或主库 binlog 被清理（
expire_logs_days过小）导致从库拉不到日志
SQL_Running=No：大概率是 SQL 线程执行出错，比如主库建了表、从库已有同名库（
Error 'Can't create database'xxx'），或主从字符集不一致导致插入失败 别急着跳过错误——先查
Last_IO_Error或
Last_SQL_Error字段，里面直接写了哪条语句、哪个库、什么错误码，比猜快得多
延迟秒数稳定上涨？大概率是大事务、无主键表或 DDL 在拖后腿
如果
Seconds_Behind_Master持续缓慢增长（比如从 0 → 120 → 300 秒），且两个线程都显示
Yes，说明复制在跑，但追不上。这时候要聚焦三类高危操作： 大事务：一个事务更新 50 万行，主库可能几秒就提交了（顺序写 binlog 快），但从库得一条条回放（随机 IO 慢），至少卡同等时长。用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY trx_started LIMIT 1查运行最久的事务 无主键表：ROW 格式 binlog 下，
UPDATE t SET a=1 WHERE b=100若表没主键，从库会全表扫描匹配每一行，100 行更新 = 100 次全表扫。用
SHOW CREATE TABLE t看有没有
PRIMARY KEY大表 DDL：主库
ALTER TABLE big_table ADD COLUMN c INT耗时 8 分钟，从库 SQL 线程也会卡 8 分钟不动，期间
Seconds_Behind_Master就直线上升
从库永远比主库慢？检查硬件、参数和复制模式是否拖了后腿
长期存在 1–5 秒固定延迟，不是故障，但暴露了底层瓶颈。常见硬伤包括：
从库用机械盘（HDD）而主库用 SSD：binlog 回放本质是大量随机写，HDD 寻道时间直接拉垮吞吐。换 SSD 或至少用 RAID10 从库配置太寒酸：innodb_buffer_pool_size只设了 1G，但数据量 50G，每次回放都要刷磁盘；建议设为物理内存的 70%~80% 还在用单线程复制（MySQL 5.6 以前默认）：主库并发高时，一个 SQL 线程根本处理不过来。升级到 MySQL 5.7+ 后，打开
slave_parallel_type=LOGICAL_CLOCK+
slave_parallel_workers=4，能按库/按事务并行回放 用了 ROW 格式却没主键：前面提过，这是双重打击——日志体积大 + 回放效率低。要么加主键，要么评估是否真需要 ROW（比如需要精确审计），否则 MIXED 更平衡
监控值忽高忽低？先确认是不是“秒级精度”在骗你
RDS 或某些监控系统显示
Seconds_Behind_Master在 0 和 1 之间跳，大概率不是真延迟，而是计算方式的副作用。MySQL 的延迟计算是“取整到秒”的： 主库事务提交时间是
10:00:00.999，从库应用完是
10:00:01.002，差值 0.003 秒 → 显示为
0但如果你在
10:00:01.005执行
SHOW SLAVE STATUS，当前时间被截成
10:00:01，减去主库时间
10:00:00→ 显示为
1所以连续采样看到 0→1→0→1，基本可忽略。真问题通常表现为 >5 秒且持续上升，或者波动幅度超过 30 秒
真正该盯的是趋势，不是瞬时抖动；排查前先看清楚，你是在修 bug，还是在给精度背锅。
