执行 SHOW SLAVE STATUSG 并检查 Slave_IO_Running 和 Slave_SQL_Running 是否均为 Yes、Seconds_Behind_Master 是否为 0 或稳定小值，是判断 MySQL 主从复制是否正常的核心方法。
要查看 MySQL 主从复制状态，核心是执行 SHOW SLAVE STATUSG 命令，并重点关注几个关键字段是否正常。以下是最常用、最有效的检查方法和判断依据。
查看主从复制整体状态
在从库（Slave）上执行：
mysql> SHOW SLAVE STATUSG
该命令会输出数十个字段，重点关注以下几项：
- Slave_IO_Running：IO 线程是否运行中，应为 Yes
- Slave_SQL_Running：SQL 线程是否运行中，应为 Yes
- Seconds_Behind_Master：从库落后主库的秒数，正常为 0 或较小稳定值（如个位数）
- Master_Host / Master_Port：确认连接的是预期的主库地址和 端口
- Relay_Log_File / Relay_Log_Pos：中继日志当前读取位置，配合 Master_Log_File / Read_Master_Log_Pos 可判断是否持续追平
快速判断是否同步异常
如果出现同步延迟或中断，常见表现有：
- 两个 Running 字段任意一个为 No → 复制已停止，需查错误日志或 Last_IO_Error / Last_SQL_Error
- Seconds_Behind_Master 持续增大 → 从库处理慢、主库写入压力大、网络延迟高或存在大事务
- Seconds_Behind_Master 为 NULL → 通常表示 SQL 线程未启动或刚启动还未开始执行事件
- Retrieved_Gtid_Set ≠ Executed_Gtid_Set（GTID 模式下）→ 中继日志已拉取但尚未执行，可能存在阻塞
辅助检查手段
仅看 SHOW SLAVE STATUS 不够时，可结合以下操作进一步定位：
- 查错误日志：tail -f /var/log/mysqld.log（路径依实际配置而定），搜索“slave”、“error”、“retry”
- 对比主从数据一致性：用 pt-table-checksum（Percona Toolkit）校验表级数据差异
- 检查主库 binlog 状态：SHOW MASTER STATUS; 确认当前正在写的 binlog 文件和位置
- 查看从库中继日志内容：mysqlbinlog /path/to/relay-log-file | head -20，确认是否能正常解析
常见修复步骤（简要）
发现异常后，典型处理流程如下：
- 先停掉复制：STOP SLAVE;
- 根据 Last_SQL_Error 内容决定是否跳过错误（慎用）：SET GLOBAL sql_slave_skip_counter = 1;（非 GTID 模式）
- GTID 模式下跳过需用：SET GTID_NEXT=’xxx-xxx-xxx:nnn’; BEGIN; COMMIT; SET GTID_NEXT=’AUTOMATIC’;
- 重新启动：START SLAVE;，再立即 SHOW SLAVE STATUSG 观察
- 若反复失败，考虑重建从库或使用备份 +binlog 恢复
