binlog 中如何定位某条 UPDATE/DELETE 记录
MySQL 本身不提供“按主键回滚单行”的能力，必须依赖
binlog手动解析还原。关键前提是：实例开启了
binlog_format = ROW，且未过期被清理。
先确认 binlog 状态：
SHOW VARIABLES LIKE 'log_bin';<br>SHOW VARIABLES LIKE 'binlog_format';若为
STATEMENT格式，无法精确还原单行变更，只能靠备份+时间点恢复，基本排除单条恢复可能。
定位记录时，用
mysqlbinlog工具配合时间或 position 过滤：
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-05-20 14:23:00" /var/lib/mysql/binlog.000012 | grep -A 5 -B 5 "WHERE id = 123"注意：
DECODE-ROWS是必须参数，否则看到的是十六进制 blob；
-v才能展开 ROW 模式下的前后镜像。
从 ROW 格式 binlog 提取 INSERT 语句的实操要点
ROW 模式下，DELETE 记录会包含
@1=123 @2='old_name'这类字段镜像，本质是“删除前的完整行”。要恢复，就得把它转成
INSERT语句。 手动提取时，重点关注
### DELETE FROM `db`.`table`后紧跟着的
### @1=...行，它们对应原表各列值（顺序与
SHOW CREATE TABLE中列定义一致） 遇到
NULL值会显示为
### @1=NULL，拼 SQL 时需保留
NULL字面量，不能写成空字符串 时间类型（如
DATETIME）在 binlog 中带微秒，但 MySQL 5.6 默认只存到秒，直接复制可能报错，建议截断到秒级：
'2024-05-20 14:23:05'如果表有自增主键，且该记录已被新数据复用 ID，恢复前得先
SET autocommit=0; START TRANSACTION;，避免触发重复键冲突
误删后立即恢复的最小安全操作链
不是所有情况都来得及停服务，但跳过某些步骤极易二次损坏：
立刻停止应用写入——哪怕只是临时FLUSH TABLES WITH READ LOCK（注意：这会阻塞所有 DML，评估业务容忍度） 用
SHOW MASTER STATUS记下当前
File和
Position，防止后续 binlog 被覆盖 不要直接在生产库执行恢复 SQL，先在同结构的测试库验证语句是否语法正确、字段数匹配、字符集无乱码 恢复时加
IGNORE（如
INSERT IGNORE INTO ...）可绕过主键冲突，但会静默丢弃冲突行，务必确认这不是你想要的行为
mysqldump + binlog 的组合恢复为何常失败
很多人以为“用最近一次 dump + 后续 binlog 到出事前”就能精准还原，实际落地卡在三个隐性条件上：
mysqldump --single-transaction生成的备份，其一致性位点在
START TRANSACTION时刻，而 binlog position 对应的是
COMMIT时刻，两者存在微小偏移，直接拼接会导致漏掉最后几条事务 如果 dump 过程中有人执行了
DDL（如
ALTER TABLE），后续 binlog 里的 ROW 事件列序可能已变，强行重放会列数不匹配报错
Error 1644: Column count doesn't match value count
mysqlbinlog默认输出含
SET @@SESSION.GTID_NEXT，若目标实例启用了 GTID，必须加
--skip-gtids参数，否则报错
The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1
单条记录恢复从来不是纯技术动作，它高度依赖 binlog 的完整性、格式一致性，以及你对那条语句在哪个事务里、哪次提交中被改写的准确判断。最容易被忽略的，其实是确认那条记录到底是在哪个 binlog 文件的哪个 event 里——而不是只盯着时间范围瞎找。
