主从同步报错应先执行show slave status\g，重点检查slave_io_running、slave_sql_running、seconds_behind_master、last_io_error和last_sql_error；常见原因包括网络/权限问题、sql执行失败、gtid事务跳过不当、表结构不一致及binlog被清理。
主从同步报错时，先看 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 能解决问题——它只是清空从库的复制元数据，不解决日志丢失的本质。
