1032错误本质是从库执行update/delete时目标行缺失，需定位binlog中具体position及条件（如@1=12345），在主库验证并导出该行数据，再导入从库补全后start slave。
1032错误不是日志损坏，而是从库执行UPDATE或DELETE时目标行确实不存在——跳过能恢复同步，但数据不一致风险立刻生效；补数据才是可落地的修复动作。
定位具体哪一行丢了
光看Last_Error里的表名和Error_code: 1032没用，关键要拿到end_log_pos和对应binlog文件名。
- 从
SHOW SLAVE STATUS\G中提取：Master_Log_File: mysql-bin.000013，Read_Master_Log_Pos: 440267874 - 在主库执行：
mysqlbinlog --no-defaults -v -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000013 | grep -A 20 "end_log_pos 440267874" - 输出里找
### DELETE FROM `db`.`t` WHERE @1=12345 AND @2='xxx'这类行——这就是丢失记录的定位条件
确认主库是否存在、导出并插入到从库
拿到条件后，先验证主库是否真有这行；有，才导出；没有，说明主库也丢了，得结合业务判断是否该恢复。
- 主库查：
SELECT * FROM db.t WHERE id = 12345;（把@1值代入） - 存在则导出：
mysqldump --no-create-info --where="id=12345" db t > missing_row.sql - 传到从库，执行前加
SET SQL_LOG_BIN = 0;（GTID模式下必须，否则INSERT又被同步回去） - 导入：
mysql db
推进SQL线程继续同步
补完数据不等于同步自动恢复，SQL thread仍卡在出错位置，必须手动推进。
- 确认从库已存在该行：
SELECT * FROM db.t WHERE id = 12345; - 执行：
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; - 检查
SHOW SLAVE STATUS\G中Slave_SQL_Running: Yes且Seconds_Behind_Master开始下降 - 若启用了
slave_exec_mode=IDEMPOTENT，可跳过SET GLOBAL SQL_SLAVE_SKIP_COUNTER，但仅限测试或容忍不一致的场景
最容易被忽略的一致性验证
补完只验证主键存在是远远不够的。字段值差异（比如datetime精度、JSON格式空格、TEXT末尾换行）会导致后续UPDATE再次触发1032，或引发隐性不一致。
- 务必比对整行：
SELECT * FROM db.t WHERE id = 12345;在主从库分别执行，逐字段肉眼或脚本比对 - 特别注意时间类型、枚举值、JSON字段、
ENUM默认值行为差异 - 如果表长期无主键，优先执行
ALTER TABLE t ADD COLUMN id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY FIRST;，避免未来再因并行复制乱序出问题
