SHOW SLAVE STATUS\G 是定位MySQL主从复制中断的唯一可靠入口，需依次检查Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running、SQL_Delay、Exec_Master_Log_Pos、Relay_Log_Pos及Last_SQL_Error等关键字段，并结合网络、权限、数据一致性、配置参数等多维度分析根因。
主从复制中断时如何快速定位错误位置
MySQL 主从复制中断后，SHOW SLAVE STATUS\G 是唯一可靠入口。重点关注 Seconds_Behind_Master（是否为 NULL）、Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes，以及最关键的 SQL_Delay、Exec_Master_Log_Pos 和 Relay_Log_Pos 是否停滞。
常见假象是 IO 线程正常但 SQL 线程卡住，此时 Seconds_Behind_Master 显示非零或 NULL，而 Last_SQL_Error 会明确报出具体语句和错误号（如 1062 Duplicate entry 或 1032 Can't find record）。
- 若
Slave_IO_Running: No，优先检查网络连通性、主库binlog是否开启、账号权限（REPLICATION SLAVE）、主库server_id是否唯一 - 若
Slave_SQL_Running: No，错误通常来自数据不一致（如从库误写、主库 DDL 未同步、GTID 模式下事务冲突），不能直接跳过，需人工核对 -
Relay_Log_Space持续增长但无进展，大概率是 SQL 线程被阻塞（如大事务未提交、锁等待），可用SHOW PROCESSLIST查看State字段是否为Waiting for table metadata lock
跳过单条错误事务的实操边界
仅当确认该事务在从库无业务影响（例如主库执行了测试 INSERT，从库已存在相同主键）且无法回滚主库操作时，才考虑跳过。跳过方式取决于复制模式：
- 基于 binlog 位置（
binlog_format=STATEMENT或MIXED）：用SET GLOBAL sql_slave_skip_counter = 1，再执行START SLAVE；注意该命令仅对当前 relay log 有效，重启后失效 - 基于 GTID（
gtid_mode=ON）：必须用SET GTID_NEXT='xxx-xxx-xxx:nnn'+BEGIN; COMMIT;注入空事务，再START SLAVE；错误的GTID_NEXT值会导致后续复制彻底紊乱 - 严禁在生产环境批量跳过（如设为 100），这会掩盖真实数据偏差，后续校验成本远高于停机修复
从库误写导致主从不一致的紧急补救
一旦发现从库被直接写入（如应用连接错库、DBA 误操作），STOP SLAVE 是第一动作。此时不能简单重启复制——主库新写入会覆盖从库“脏数据”，造成不可逆丢失。
正确路径是先导出从库异常表的变更行（用 mysqldump --where 或解析 relay-log 找出 INSERT/UPDATE/DELETE），再对比主库对应时间点的 binlog，判断哪些是冗余写入、哪些是缺失同步。工具上可借助 pt-table-checksum 和 pt-table-sync，但需注意：
-
pt-table-sync默认生成REPLACE INTO，若从库有额外索引或触发器，可能引发意外行为 - 跨版本同步（如主库 8.0，从库 5.7）时，
JSON或Generated Column类型字段会失败，必须提前过滤 - 大表修复期间，务必关闭
slave_parallel_workers，避免并行应用加剧不一致
配置参数错误引发的隐性故障
很多主从异常并非复制链路断开，而是配置项逻辑冲突。典型例子：replicate-ignore-db=test 在语句级复制下完全失效（因为 USE test; INSERT INTO otherdb.t1 不会被忽略），必须改用 replicate-wild-ignore-table=test.%。
其他高危配置：
-
innodb_flush_log_at_trx_commit=2+sync_binlog=0组合：主库崩溃可能导致已提交事务丢失，从库永远追不上，且无错误提示 -
slave_net_timeout过大（如设为 3600）：IO 线程在主库短暂不可达时不会及时重连，表现为长时间Seconds_Behind_Master持续增加 -
max_allowed_packet主从不一致：主库允许大包，从库拒绝解析，SQL 线程报错Packet too large，但错误日志可能被淹没在常规 warning 中
修复这类问题必须逐项比对主从 my.cnf 中所有以 replicate-、slave-、binlog- 开头的参数，而不是只盯着 CHANGE MASTER TO 语句。
