必须先登录MySQL客户端再执行SHOW SLAVE STATUS，该命令不是Shell命令；排查时重点看Last_IO_Error和Last_SQL_Error字段，依错误类型检查网络、权限、数据一致性或binlog位点。
SHOW SLAVE STATUS 命令报 “bash: show: command not found” 怎么办
这不是 MySQL 出错了，是你在 Shell 里直接敲了 SQL 命令。SHOW SLAVE STATUS 是 MySQL 客户端内的 SQL 指令，不是 Linux 命令。
- 必须先登录 MySQL：比如
mysql -u root -p，输密码进到mysql>提示符下再执行 - 如果用 Docker，得先
docker exec -it mysql_slave1 bash进容器，再进 MySQL - 结尾加
\G是为了竖排显示，比;更易读状态字段（如Slave_IO_Running、Last_SQL_Error）
Slave_IO_Running: No 或 Slave_SQL_Running: No 怎么排查
这两个值只要有一个是 No，复制就卡住了。关键看 Last_IO_Error 和 Last_SQL_Error 字段——它们才是真正的“错误说明书”。
-
Slave_IO_Running: No多半是连不上主库：检查网络（telnet master_ip 3306）、防火墙、主库是否监听公网（bind-address是否为0.0.0.0或从库 IP）、复制用户权限（GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip'） -
Slave_SQL_Running: No说明中继日志拉下来了，但执行失败：常见于主键冲突（Duplicate entry for key）、表不存在（Table xxx doesn't exist）、数据类型不兼容（如主库 datetime 插入了0000-00-00，但从库 sql_mode 严格） - 别急着跳过：先确认错误是否可安全忽略；测试环境可用
SET GLOBAL sql_slave_skip_counter = 1，生产环境优先考虑修复数据或重搭从库
CHANGE MASTER TO 执行后 START SLAVE 报 “Could not find first log file name”
这是典型的 binlog 文件名或位置错位。从库想接着读某个 mysql-bin.0000xx 文件的某 pos，但主库上该文件已被 purged 或压根没生成过。
- 在主库查当前 binlog 状态：
SHOW MASTER STATUS，记下File和Position - 在从库执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=yyyyy，确保文件名和位置完全匹配 - 如果主库 binlog 已清理，且从库落后太多，
mysqldump --master-data=2全量重导 +RESET SLAVE是更稳妥的选择 - 预防：主库配置
expire_logs_days = 7（别设太短），从库开启log_slave_updates方便级联复制
主从数据不一致导致复制中断，但不敢随便跳过
跳过错误看似快，但可能掩盖更大问题。真正要问的是：这条语句为什么在从库执行不了？它反映的是数据、结构还是逻辑层面的偏差？
- 主键冲突（
ERROR 1062）：先查从库是否存在该记录，再决定是删从库脏数据（SET sql_log_bin=0; DELETE ...），还是补缺失数据 - 找不到记录（
ERROR 1032）：用mysqlbinlog --base64-output=decode-rows -v解析对应 binlog 片段，确认主库执行的是 INSERT 还是 UPDATE，再手动补数据 - 表结构不一致（如从库少个字段）：
mysqldump -d导出主库 DDL，对比并同步从库结构；注意ALTER TABLE是否被正确记录进 binlog（ROW 格式下 DDL 不写入 binlog，但 DML 会）
最危险的操作不是停复制，而是没看懂 Last_SQL_Error 就敲下 sql_slave_skip_counter。复制中断本身不可怕，可怕的是把不一致当成“已同步”。
