1032错误需定位具体丢失行：从SHOW SLAVE STATUS中提取Master_Log_File与Read_Master_Log_Pos，用mysqlbinlog解析对应binlog位置，找到DELETE/UPDATE的WHERE条件（如@1=12345），在主库验证后导出该行数据，从库SET SQL_LOG_BIN=0导入，再跳过当前事件恢复同步。
1032错误不是日志坏了，而是从库真没那条数据——必须定位到具体哪一行、在哪条binlog里丢了，才能修复。
怎么从Last_Error里挖出关键定位信息
只看Last_Error: Can't find record in 'db.t'毫无用处。真正要抓的是：Master_Log_File: mysql-bin.000013 和 Read_Master_Log_Pos: 440267874（或end_log_pos 440267874）。这两个值共同锁定了出错的binlog文件和精确位置。
- 别信
Relay_Master_Log_File和Exec_Master_Log_Pos——它们可能已滞后，得用Master_Log_File+Read_Master_Log_Pos - 如果启用了GTID，
Retrieved_Gtid_Set末尾那个事务号才是真实执行位点，Read_Master_Log_Pos可能不准 - 在GTID模式下，
SHOW SLAVE STATUS\G里Auto_Position: 1表示走GTID同步，此时跳过事务必须用SET GTID_NEXT方式，不能用SQL_SLAVE_SKIP_COUNTER
如何用mysqlbinlog反查丢失行的WHERE条件
拿到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或### UPDATE开头的行，后面跟着类似WHERE @1=12345 AND @2='xxx'的内容——这就是从库缺失记录的完整定位条件。
-
@1通常对应表的第一列（很可能是主键），但不绝对；必须结合SHOW CREATE TABLE确认字段顺序 - 如果表没有主键，
@1~@N是整行所有字段的镜像，WHERE条件会非常长，且容易因字段值微小差异（如JSON空格、datetime毫秒）导致匹配失败 -
--base64-output=DECODE-ROWS必须加，否则看到的是BASE64编码，无法人工识别条件
为什么导出再导入时SET SQL_LOG_BIN = 0不能省
在从库导入缺失数据前，必须执行SET SQL_LOG_BIN = 0（GTID模式下强制要求），否则这条INSERT会被记入从库binlog，并同步回主库，引发主键冲突或循环写入。
- 非GTID模式下，
SQL_LOG_BIN关闭后导入的数据不会进入binlog，但需确保binlog_format = ROW（否则可能被忽略） - 导入命令必须用
mysql db_name < missing_row.sql，不能用source，否则SQL_LOG_BIN = 0对source无效 - 如果从库开了
slave_exec_mode = IDEMPOTENT，UPDATE/DELETE失败会自动转为INSERT，但仅适用于测试环境，生产慎用
补完数据后为什么START SLAVE还是卡住
补数据只是解决了“行不存在”，但SQL线程仍停在原错误位置，必须手动推进一次事件才能继续执行后续binlog。
- 先确认该行已在从库存在：
SELECT * FROM db.t WHERE id = 12345（务必用实际条件） - 执行
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE;——这是最通用做法 - GTID模式下必须改用：
STOP SLAVE; SET @@SESSION.GTID_NEXT = 'xxx:yyy'; BEGIN; COMMIT; SET SESSION GTID_NEXT = AUTOMATIC; START SLAVE; - 推进后立刻检查
Seconds_Behind_Master是否开始下降，而不是只看Slave_SQL_Running: Yes
最容易被跳过的动作是：补完数据后只验证主键存在，却没比对整行字段值。时间戳精度、JSON格式、TEXT末尾换行符这些肉眼难辨的差异，会在下一次UPDATE时再次触发1032——必须在主从库分别执行SELECT * FROM db.t WHERE id = 12345，逐字段比对。
