SHOW SLAVE STATUS\G 是 MySQL 客户端内命令，非 Shell 命令；需先登录 mysql -u root -p 后执行，Docker 环境须先进容器；Slave_IO_Running: No 表示 IO 线程异常，多因网络或权限问题；Slave_SQL_Running: No 表示 SQL 线程异常，需查 Last_SQL_Error；Seconds_Behind_Master 高常因大事务或未启用并行复制；跳过错误事件在 GTID 模式下不可用 SQL_SLAVE_SKIP_COUNTER，须用 GTID_NEXT 方式；主从复制不等于高可用，故障转移需额外工具保障。
为什么 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 自己不保证。
