主从同步报错时，先看 SHOW SLAVE STATUS\G
的关键字段
绝大多数复制异常都能从这个命令的输出里定位根源。重点关注
Slave_IO_Running、
Slave_SQL_Running、
Seconds_Behind_Master、
SQL_Delay和最核心的
Last_IO_Error与
Last_SQL_Error。
常见错误现象：
Slave_IO_Running: No：通常意味着网络不通、主库权限不足、或主库
binlog被清理导致找不到指定日志文件
Slave_SQL_Running: No：说明中继日志（relay log）里的某条语句在从库执行失败，比如主键冲突、表结构不一致、函数不可用等
Seconds_Behind_Master: NULL且 SQL 线程未运行：大概率是 SQL 线程卡在某个错误上，必须手动干预
跳过单条出错的 SQL（SET GLOBAL sql_slave_skip_counter = 1
）慎用
这个命令只对基于语句复制（SBR）有效，且仅跳过下一条事件；对基于行复制（RBR）基本无效（MySQL 5.7+ 默认 RBR），强行使用可能造成主从数据不一致。
更安全的做法是用
gtid_next跳过：
STOP SLAVE; SET GTID_NEXT='f8e7f9b2-1a3c-11ef-8a12-00155d012345:12345'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;
其中
f8e7f9b2-1a3c-11ef-8a12-00155d012345:12345是
Last_SQL_Error中提示的出错事务 GTID。务必先确认该事务确实可丢弃（例如是测试数据、重复插入等），否则跳过会引发主从差异。
主从表结构不一致导致的 Column count doesn't match value count
这是 RBR 模式下非常典型的错误：主库写入时用了
INSERT INTO t(a,b) VALUES(1,2)，但从库表
t多了一列
c（或少了一列），导致解析 binlog 行事件失败。
排查步骤：
对比主从库对应表的SHOW CREATE TABLE t\G输出 检查是否启用了
slave_type_conversions（默认为空，不自动兼容类型差异） 确认 DDL 是否只在主库执行、且已正确同步到从库（注意
ALTER TABLE在 RBR 下也会记录为事件）
修复建议：优先用
pt-online-schema-change或
gh-ost做在线 DDL，避免主从结构漂移；若已出错，先停从库，手工补全缺失列或删除冗余列，再
START SLAVE。
主库 binlog 被清理，从库报 Could not find first log file name in binary log index file
说明从库需要读取的 binlog 文件（如
mysql-bin.000123）已在主库被
PURGE BINARY LOGS或过期策略删除。
此时无法靠常规方式恢复同步，只能：
重新做一次全量同步（mysqldump+
CHANGE MASTER TO ... MASTER_LOG_FILE指向最新 binlog） 启用
binlog_expire_logs_seconds（MySQL 8.0.14+）替代旧的
expire_logs_days，设为足够长（如 604800 秒 = 7 天）防止误删 监控从库的
Seconds_Behind_Master，一旦延迟过大，及时介入，避免追日志时触发清理
别指望
RESET SLAVE能解决问题——它只是清空从库的复制元数据，不解决日志丢失的本质。
