直接执行SHOW SLAVE STATUS\G，检查Slave_IO_Running和Slave_SQL_Running是否均为Yes；若任一为No则同步中断，Seconds_Behind_Master持续增长表明SQL线程假运行。
怎么看 IO 和 SQL 线程是否正常运行
直接连上从库执行 SHOW SLAVE STATUS\G，重点盯住两行：Slave_IO_Running 和 Slave_SQL_Running。只要其中一个是 No，同步就断了。
常见错误现象：两个值都显示 Yes，但 Seconds_Behind_Master 持续增长，说明 SQL 线程在“假装运行”——它可能卡在某个事务里没报错，但实际已滞后。
-
Slave_IO_Running = No：通常意味着从库连不上主库（网络、账号权限、主库 binlog 关闭等） -
Slave_SQL_Running = No：大概率是 SQL 执行出错，比如主库写了唯一键冲突、表结构不一致、或从库误删了某张表 - 两者都是
Connecting：主库地址/端口写错了，或者主库防火墙没放行 3306
IO 线程连不上主库的典型原因和检查顺序
先别急着查配置文件，用最简方式验证连通性：从从库机器上手动 mysql -h 主库IP -P 主库端口 -u 复制账号 -p。连不上，问题就出在这层。
- 主库是否开启了
log_bin？查SELECT @@log_bin;，返回 0 就不行 - 复制账号有没有
REPLICATION SLAVE权限？SHOW GRANTS FOR 'repl_user'@'%'; - 主库
bind_address是不是写死了127.0.0.1？得改成0.0.0.0或具体内网 IP - 从库的
CHANGE MASTER TO语句里，MASTER_HOST写的是域名？DNS 解析失败时会卡在Connecting，建议改用 IP
SQL 线程报错后怎么快速定位和恢复
一旦 Slave_SQL_Running = No，立刻看 Last_SQL_Error 字段。90% 的问题靠这一行就能判断方向。
- 错误含
Duplicate entry：主从数据不一致，常见于从库被手动写入过。可跳过当前事件：SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;（仅限测试环境或明确知道后果时） - 错误含
Table doesn't exist：从库少了某张表，可能是误操作或 DDL 未同步成功。不要直接建表，先确认主库是否存在、是否被replicate-ignore-table过滤 - 错误含
Deadlock或超时：检查从库负载，innodb_lock_wait_timeout是否太小；也可能是主库有长事务阻塞了从库回放 - 想临时绕过所有错误继续同步？别用
slave_skip_errors全局配置，风险太高；优先用sql_slave_skip_counter精确跳过单条
为什么 Seconds_Behind_Master 显示 0 却明显不同步
这个值只反映 relay log 中最后一个事务的时间戳和当前系统时间的差值，不是真实延迟。当 SQL 线程空闲、IO 线程还在拉日志时，它就会“骗人”显示 0。
真正靠谱的判断方式是对比主从的 Exec_Master_Log_Pos 和 Read_Master_Log_Pos：
- 如果
Read_Master_Log_Pos > Exec_Master_Log_Pos，说明 relay log 已拉取但还没执行完 - 如果两者相等，但
Seconds_Behind_Master = 0，再查主库SHOW MASTER STATUS的Position，三者比对才能确认是否真同步完成 - 高并发场景下，SQL 线程单线程回放容易成为瓶颈，
Seconds_Behind_Master突然飙升又缓慢回落，往往是积压导致，不是故障
最易被忽略的是：主库 max_allowed_packet 设得太小，导致大事务被截断，从库解析 relay log 失败却不报明显错误，只表现为缓慢追平或随机卡住。
