1032 行不存在怎么处理
从库 SQL 线程报 1032 表示要删除或更新的行在从库上找不到，通常源于三类原因：历史上用跳过方式处理过错误、从库数据被单独清理或修改、主从在某个时间点起就不再严格一致。报错里会带上具体的主键值，可据此定位到具体数据。
基本信息
| 适用 | MySQL 5.7 / 8.0 复制环境 |
|---|---|
| 报错特征 | Could not execute Delete_rows 或 Update_rows，附主键值 |
| 根因 | 历史跳过事务、从库数据被清理、数据修复不当 |
| 处理底线 | 采用跳过方式时必须记录并在后续一致性校验中复查 |
定位与处理
定位与处理
SHOW REPLICA STATUS\G # 看 Last_SQL_Errno 与 Last_SQL_Error 的完整内容
SELECT COUNT(*) FROM appdb.orders WHERE id = 88991; # 用报错里给出的主键值确认行是否存在
SELECT * FROM appdb.orders WHERE id = 88991; # 必要时对比主库同行的内容
-- 方案一：从源端补回该行，再恢复重放（优先，尽量保持数据一致）
-- 方案二：按 GTID 跳过该事务（必须留档，事后做一致性校验）
SELECT @@GLOBAL.gtid_executed; # 记录跳过前后的 GTID 位置
-- 校验工具：pt-table-checksum 做全库一致性核对常见根因与判断
| 根因 | 表现 | 处理方向 |
|---|---|---|
| 历史跳过事务 | 错误集中在某些主键区间 | 补齐数据后校验，避免继续累积 |
| 从库数据被清理 | 从库缺少主库存在的行 | 从源端补行或重建从库 |
| 主从数据不一致 | 同类错误反复出现 | 做一致性校验并评估重建 |
| 数据修复脚本出错 | 错误出现时间与操作时间吻合 | 核对脚本并对齐数据 |
| 主键冲突（1062）成对出现 | 插入找不到目标的相反情况 | 两者都是数据漂移症状，统一治理 |
典型使用场景
- 复制中断后快速判断是数据问题还是配置问题
- 跳过事务前评估影响，避免无记录的操作
- 巡检脚本定期检查从库错误与延迟
- 一致性校验发现问题后的修复路径选择
- 事故复盘：追溯历史上跳过操作留下的隐患
补数据时要注意与重放竞争：建议先停住 SQL 线程、补完数据再启动，否则补入的行可能再次冲突。
只跳过不核查会让漂移越滚越大，最终只能重建从库；每一次跳过都必须记录主键值与原因，并纳入后续校验清单。