MySQL 8.0 主从复制报 1032 错误意味着从库执行 UPDATE 或 DELETE 时找不到目标行，最稳妥的修复方案是定位主库 binlog 缺失记录的具体位置，导出该行数据补入从库，再跳过错误事件。直接跳过错误虽能恢复同步，但会导致主从数据永久不一致，仅适用于容忍数据缺失的场景。

命令速用版

以下命令用于快速定位错误位置并跳过事务，适用于紧急恢复同步场景。

-- 1. 查看错误位置
SHOW SLAVE STATUS\G
-- 关注 Master_Log_File 和 Read_Master_Log_Pos

-- 2. 跳过错误事件（传统模式）
STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

-- 3. 跳过错误事件（GTID 模式）
STOP SLAVE;
SET GTID_NEXT='xxx:xx'; -- 替换为 Retrieved_Gtid_Set 中报错的 GTID
BEGIN; COMMIT;
SET GTID_NEXT='AUTOMATIC';
START SLAVE;

为什么会这样

1032 错误直接原因是从库执行更新或删除指令时，目标记录在从库表中不存在。这通常不是日志损坏，而是数据不一致导致的。在 MySQL 8.0 并行复制场景下，无主键表或历史批量导入时使用 sql_log_bin=0 可能导致主库有数据而从库缺失，当主库同步更新操作时，从库因找不到旧记录而报错。

分步处理

修复核心在于补全缺失数据，而非单纯跳过错误，以下是基于 binlog 定位的修复流程。

第一步：定位 binlog 坐标与条件

在从库执行 SHOW SLAVE STATUS\G，提取 Master_Log_File（如 mysql-bin.000013）和 Read_Master_Log_Pos（如 440267874）。在主库执行 mysqlbinlog 解析该位置，找到类似### DELETE FROM `db`.`t` WHERE @1=12345 的行，获取缺失记录的主键条件。

mysqlbinlog `--no-defaults` -v -v `--base64-output`=DECODE-ROWS /var/lib/mysql/mysql-bin.000013 | grep -A 20 "end_log_pos 440267874"

第二步：从主库导出缺失数据

使用获取到的主键条件在主库验证记录存在，然后导出 SQL 文件。注意不要使用 INSERT INTO SELECT 直连从库，避免网络中断导致数据半截。

-- 主库验证
SELECT * FROM db.t WHERE id = 12345;
-- 主库导出
mysqldump `--no-create-info` `--where`="id=12345" db t > missing_row.sql

第三步：导入从库并跳过错误

将文件传至从库，导入前必须执行 SET SQL_LOG_BIN = 0，防止 GTID 模式下 INSERT 操作又被同步回主库造成死循环。导入后手动跳过报错事务。

-- 从库操作
STOP SLAVE;
SET SQL_LOG_BIN = 0;
SOURCE missing_row.sql;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
START SLAVE;

怎么验证是否生效

修复后需确认复制线程状态及数据一致性，避免隐性差异导致再次报错。

执行 SHOW SLAVE STATUS\G，确认 Slave_SQL_Running 为 Yes 且 Seconds_Behind_Master 开始下降。分别在主从库执行 SELECT * FROM db.t WHERE id = 12345，逐字段比对内容，特别注意时间类型、JSON 字段格式及 TEXT 末尾换行符差异。

常见坑

操作过程中有几个高风险点容易导致修复失败或引发新问题。

• GTID 模式漏设 SQL_LOG_BIN：在从库补数据时若不开启 SQL_LOG_BIN = 0，插入操作会生成新 GTID 并同步回主库，造成主从循环复制。
• 仅验证主键存在：补全数据后若字段值不一致（如 datetime 精度差异），后续 UPDATE 仍可能触发 1032 或隐性不一致，务必比对整行内容。
• 无主键表风险：若表长期无主键，优先执行 ALTER TABLE 添加自增主键，避免并行复制乱序导致未来再次出现找不到记录问题。

常见问题

1032 错误可以直接跳过吗？

可以但不推荐。跳过错误能恢复同步状态，但会导致从库永久缺失该条数据，若业务依赖从库查询则会造成数据不一致，仅建议在容忍数据缺失的测试环境使用。

GTID 模式下如何跳过特定事务？

需先通过 SHOW SLAVE STATUS 获取 Retrieved_Gtid_Set 中报错的 GTID 值，执行 SET GTID_NEXT='xxx:xx' 后运行空事务 BEGIN; COMMIT;，再重置 GTID_NEXT='AUTOMATIC' 并启动同步。

为什么主库有数据从库却没有？

常见于历史批量导入或修复数据时使用了 sql_log_bin=0，导致操作未写入 binlog 同步到从库，或者人工直接在从库执行了 DELETE 操作破坏了一致性。

参考来源

• 如何修复 MySQL 主从复制中 1032 找不到记录的报错？
• MySQL 从库报 1032 找不到记录错误时该如何跳过或修复？
• mysql 主从同步出现 1032 找不到记录怎么办_补全缺失数据技巧
• MySQL 8.0 主从复制严重不一致修复实战指南 (基于 Binlog Position)
• MySQL 复制报错 1032 的补充原因:`sql_log_bin=0`
• 解决 Mysql 主从或主主报 1032 错误_slave-skip-errors = 1032-CSDN 博客