最准的判断是执行SHOW SLAVE STATUS\G并确认Slave_IO_Running和Slave_SQL_Running均为Yes，否则复制中断；若均为Yes但复制不动，需结合Slave_IO_State、Slave_SQL_Running_State、SHOW PROCESSLIST及Relay_Log_Space等综合判断。
直接看 SHOW SLAVE STATUS\G 里的两个关键字段
不用猜、不用绕，最准的判断就是进从库 MySQL 客户端执行 SHOW SLAVE STATUS\G，然后盯死这两行：
-
Slave_IO_Running：必须是 Yes，否则 IO 线程没连上主库，或中途断开了 -
Slave_SQL_Running：必须是 Yes，否则 SQL 线程卡住、报错或被手动停了
只要任一为 No，复制就已中断。注意别在 shell 里直接敲这个命令——bash: show: command not found 是典型误操作。
线程“是 Yes”但复制不动？查 Slave_IO_State 和 Slave_SQL_Running_State
Slave_IO_Running = Yes 只代表线程活着，不代表它在干活；同理，Slave_SQL_Running = Yes 也不等于 SQL 正在回放。得看状态描述：
- 如果
Slave_IO_State是Waiting for master to send event，说明主库当前没新 binlog，IO 层其实空闲，不是故障 - 如果
Slave_SQL_Running_State是Waiting for table metadata lock或Waiting for commit lock，基本可断定被 DDL 或长事务锁住了，不是复制慢，是被堵死了 - 若状态长期卡在
Reading event from the relay log且Seconds_Behind_Master持续上涨，大概率是 SQL 回放慢（比如大 UPDATE、磁盘 I/O 差、没开并行）
用 SHOW PROCESSLIST 验证线程是否真在跑
SHOW SLAVE STATUS 是快照，SHOW PROCESSLIST 能看到实时线程行为。在从库执行：
SHOW PROCESSLIST\G
重点找两行 User 为 system user 的记录：
- 其中一行
Command是Connect、State类似Queueing master event to the relay log→ IO 线程正常拉日志 - 另一行
Command是Connect、State类似Executing event或Waiting for dependent transaction to commit→ SQL 线程正在工作或被阻塞 - 如果这两行完全消失，或者
State是NULL/Has read all relay log后长期不动，线程实际已停滞
别只信 Seconds_Behind_Master，它经常撒谎
这个值是估算值，很多场景下会失真：
- 主库长时间没写入，它可能显示
0，但 IO 线程其实在重连或权限失效 - SQL 线程卡在锁上，它可能卡在某个非零值（比如
42）不动，既不涨也不降 - 大事务执行中，它会突增至几百秒，但事务结束后自动归零——这不是故障，是正常现象
- 更隐蔽的是
Relay_Log_Space持续增长却不见下降：说明 relay log 在疯狂堆积，SQL 线程根本没消费，但Seconds_Behind_Master可能还是0或NULL
真正可靠的组合判断是：Slave_IO_Running = Yes + Slave_SQL_Running = Yes + Relay_Log_Space 不持续上涨 + Seconds_Behind_Master < 60。少一个条件，都可能漏掉真实问题。
