主从复制报错 1063 通常意味着从库表结构与主库不一致，忽略错误仅适用于确认该语句不影响数据一致性的紧急场景。操作前必须停止复制，跳过事务后需立即校验数据差异，否则可能导致主从数据永久不一致。

命令速用版

根据是否开启 GTID 模式，选择对应的跳过命令执行。

未开启 GTID 模式：

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE;

已开启 GTID 模式：

STOP SLAVE;
SET GTID_NEXT='报错事务的 GTID';
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

为什么会这样

报错 1063 的根本原因是主从库表结构定义不一致，导致复制线程无法apply 行数据。

在主从复制中，如果主库执行了 DDL 变更但从库未同步，或者从库表被手动修改，主库传来的行数据列数与从库表结构不匹配，SQL 线程就会抛出 Incorrect column count。忽略错误本质是告诉从库跳过这条无法执行的语句，但跳过意味着从库少执行了一次操作，数据会产生差异。

分步处理

按顺序执行以下步骤，确保操作可回滚。

步骤 1：确认复制状态和 GTID 模式

执行 SHOW SLAVE STATUS\G，查看 Slave_SQL_Running 是否为 No，并确认 Executed_Gtid_Set 是否有值。如果有 GTID 集合，说明开启了 GTID 模式，不能使用 sql_slave_skip_counter。

步骤 2：停止从库同步

执行 STOP SLAVE; 确保 SQL 线程完全停止，避免在设置跳过参数时新事务进入。

步骤 3：执行跳过操作

若未开启 GTID，执行 SET GLOBAL sql_slave_skip_counter = 1;。若开启 GTID，需从报错日志中找到 Next_Gtid，执行 SET GTID_NEXT='xxx'; BEGIN; COMMIT; 重置为 AUTOMATIC。

步骤 4：重新启动同步

执行 START SLAVE; 观察错误是否消失。如果报错依旧，说明跳过未生效或连续多条错误，需评估是否增加跳过次数或修复表结构。

怎么验证是否生效

执行 SHOW SLAVE STATUS\G，关注以下字段判断恢复情况。

Slave_SQL_Running 应为 Yes，表示 SQL 线程已启动。Last_Error 应为空，表示当前无报错。Seconds_Behind_Master 应逐渐减小至 0，表示延迟消除。若这些状态正常，说明跳过操作生效，复制链路恢复。

常见坑

忽略错误操作存在明确边界，以下场景需谨慎。

GTID 模式下使用 skip_counter 会直接报错 1755，必须使用 GTID_NEXT 空事务方法。跳过 DML 语句（INSERT/UPDATE）会导致主从数据行级不一致，后续校验困难。连续报错时盲目增加跳过次数可能跳过正常业务数据，应先分析报错日志确认错误类型是否相同。

常见问题

GTID 模式下能直接用 sql_slave_skip_counter 吗

不能，GTID 模式下该参数无效，会报 1755 错误。

必须使用 SET GTID_NEXT 注入空事务的方式跳过特定事务 ID。

跳过错误后数据会自动一致吗

不会，跳过意味着从库少执行了该事务，数据必然不一致。

后续需要通过 pt-table-checksum 等工具校验差异，并在低峰期修复表结构或补数据。

如何永久解决 1063 报错

永久解决需要统一主从表结构，而不是跳过错误。

应在从库执行与主库相同的 DDL 语句，确保列数和类型完全一致，然后重置复制位置。