1032错误本质是从库执行delete/update时目标行缺失，需定位binlog中具体position及条件（如@1=12345），在主库验证并导出该行数据，再导入从库补全后start slave。
1032 错误本质是「从库执行 DELETE/UPDATE 时找不到目标行」，不是日志损坏，而是数据本身缺失。跳过错误最省事，但数据一致性风险立刻落地——补全数据才是治本动作。
查清到底是哪条记录丢了
光看 Last_SQL_Error 里的表名和错误码没用，关键要定位到具体哪一行被删了、在哪条 binlog 里、哪个 position。
- 从
Last_SQL_Error提取master log mysql-bin.000013, end_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_test`.`tbuservcbgolog` WHERE @1=12345 AND @2='xxx'——这就是要删的那行的主键或唯一条件
从主库捞出缺失数据再插回从库
拿到条件后，直接去主库查这条记录是否存在。存在，就导出来；不存在，说明主库也丢了，得结合业务逻辑判断是否该恢复。
- 主库执行：
SELECT * FROM db_test.tbuservcbgolog WHERE id = 12345;（把@1值代入） - 如果查到结果，用
mysqldump --no-create-info --where="id=12345" db_test tbuservcbgolog > missing_row.sql导出 - 传到从库，先关同步：
STOP SLAVE;，再导入：mysql db_test - 注意：如果是 GTID 模式，导入前加
SET SQL_LOG_BIN = 0;，避免这条 INSERT 又被同步回去
补完后别急着 start slave
补数据只是修复了「缺失」，但 binlog 位置还在出错点卡着，必须手动推进 SQL thread 才能继续。
- 确认从库已存在那条记录：
SELECT * FROM db_test.tbuservcbgolog 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这步，但仅限测试或容忍少量不一致的场景
最容易被忽略的是：补数据后没验证主从该行内容是否完全一致（比如时间戳、JSON 字段格式），而不仅仅是主键存在。一旦字段值不同，后续 UPDATE 仍可能触发 1032 或隐性不一致。补完务必比对整行内容。
