直接登录从库MySQL执行SHOW SLAVE STATUS\G，重点检查Slave_IO_Running、Slave_SQL_Running和Seconds_Behind_Master三个字段：前两者须为Yes，后者应接近0；若异常则分别查Last_IO_Error和Last_SQL_Error定位问题。
直接登录从库的 MySQL 客户端，执行 SHOW SLAVE STATUS\G 即可查看主从复制状态。关键不是看全量输出，而是盯住几个核心字段——它们能快速告诉你复制是否健康、有无延迟或错误。
从库上执行 SHOW SLAVE STATUS\G 查状态
这是最标准、最直接的方式。注意必须在从库的 MySQL 命令行中执行，不能在 Linux shell 下直接敲（否则会报 bash: show: command not found）。执行后垂直显示更清晰，便于定位字段：
- 务必使用 \G 而非分号，避免信息挤成一行
- 如果提示权限不足，说明当前用户无 SUPER 或 REPLICATION CLIENT 权限，需用高权限账号（如 root）登录
- 输出为空或报错 “ERROR 1227 (42501)” 时，大概率是从库未启用复制或配置不完整
重点检查三个核心字段
不用通读全部 30+ 个字段，只关注这三个就能判断 90% 的问题：
- Slave_IO_Running：应为 Yes。表示从库 IO 线程正在连接主库、拉取 binlog。若为 No，常见原因是网络不通、主库防火墙拦截、复制用户无权限或主库 binlog 关闭
- Slave_SQL_Running：应为 Yes。表示 SQL 线程正在回放中继日志。若为 No，通常是执行 SQL 出错，比如主键冲突、表结构不一致、从库被误写
- Seconds_Behind_Master：理想值是 0 或较小正整数（如 ≤ 1–2 秒）。若为 NULL，说明复制已中断；若持续大于 60，需查负载、大事务或慢查询阻塞
快速发现错误的两个字段
一旦复制异常，错误信息就藏在这两个地方，优先扫一眼：
- Last_IO_Error：IO 层错误。例如 “error connecting to master”、“Access denied for user”，说明连不上主库，要查网络、端口、用户权限、主库 bind-address 配置
- Last_SQL_Error：SQL 层错误。例如 “Duplicate entry for key 'PRIMARY'”、“Table doesn't exist”，说明中继日志里某条语句在从库无法执行，需人工干预或跳过（慎用）
辅助验证命令（按需使用）
当主从状态看起来正常但仍有疑虑时，可用这些命令交叉核对：
- 在主库执行 SHOW MASTER STATUS;，获取当前 binlog 文件名和 Position；再对比从库 Master_Log_File 和 Read_Master_Log_Pos 是否一致，确认拉取点没偏移
- 在从库执行 SHOW PROCESSLIST;，查找 User 为 system user 的两行：一行标 “I/O thread”，一行标 “SQL thread”，确认它们状态为 “Waiting for master to send event” 和 “Slave has read all relay log”
- 用 SHOW BINARY LOGS;（主库）或 SHOW RELAYLOG EVENTS;（从库）查看日志文件是否存在、是否滚动，排除磁盘满或日志被误删
