为什么 SHOW SLAVE STATUS\G
报错或找不到命令？
这不是 MySQL 出了问题，而是你把它当成了 Shell 命令执行。
SHOW SLAVE STATUS是 MySQL 客户端内的 SQL 语句，不能在 Linux 终端直接敲——否则会报
bash: show: command not found。 必须先登录 MySQL 客户端：
mysql -u root -p，输密码后进入
mysql>提示符 再执行：
SHOW SLAVE STATUS\G（注意末尾
\G是格式化输出，不是必须但强烈推荐） 如果用 Docker，别忘了先进容器：
docker exec -it mysql_slave1 bash，再连 MySQL
Slave_IO_Running: No
和 Slave_SQL_Running: No
分别意味着什么？
从库靠两个线程工作：IO 线程负责拉 binlog，SQL 线程负责执行。一个挂了，复制就断；两个都挂，数据彻底不同步。
Slave_IO_Running: No→ 主要查网络和权限：
telnet master_ip 3306看通不通；主库是否授权了从库 IP：
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip' IDENTIFIED BY 'xxx';
Slave_SQL_Running: No→ 看
Last_SQL_Error字段，常见如
1062 Duplicate entry（主键冲突）、
1050 Table already exists（表已存在）、
1032 Can't find record（从库缺行） 别急着
START SLAVE，先确认错误可跳过还是需修复；误跳可能丢数据
主从延迟高，Seconds_Behind_Master
一直涨怎么办？
这个值只是估算，不准但有参考价值。真正卡住的往往是 SQL 线程串行回放——主库并行写的 N 条事务，从库只能一条条执行。
检查是否启用了并行复制：SELECT @@slave_parallel_type;应为
LOGICAL_CLOCK（MySQL 5.7+），且
slave_parallel_workers > 0大事务是最大杀手：比如一个
UPDATE改了百万行，会阻塞后续所有 relay log 回放；建议拆成小批量 避免在从库写入：
read_only=ON是基础，但 5.7+ 还得加
super_read_only=ON防绕过 如果延迟突然飙升，立刻查
SHOW PROCESSLIST看 SQL 线程是否卡在某个慢查询上
复制中断后，能直接 SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1
吗？
仅适用于传统复制（非 GTID 模式），且只跳过**一个事件**（不一定是完整事务）。GTID 环境下跳过必须用
SET GTID_NEXT+ 空事务方式，否则会破坏 GTID 集合一致性。 跳之前务必确认：
Relay_Log_File和
Relay_Log_Pos对应的 binlog 内容是否真的可丢（比如只是建了个测试表） 更安全的做法是解析 binlog：
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 | grep -A 10 -B 5 "xxx"，看清出错那条到底干了啥 跳过不是常态方案，频繁跳说明架构或应用有问题：比如没关
sql_log_bin就在从库手动改数据，或者主库用了
CREATE TEMPORARY TABLE这类不记 binlog 的语句
最常被忽略的一点：主从复制不是故障转移方案。它解决的是读扩展和基础容灾，但主库宕机后，从库是否能升主、升主后数据是否完整、GTID 是否连续、自增 ID 是否冲突……这些全得靠额外机制（MHA、Orchestrator、或自己脚本）兜底，MySQL 自己不保证。
