必须配合全量备份+binlog增量回放才能恢复单行误删数据；row格式下binlog记录被删行完整快照，statement格式仅记录sql语句，且需确保日志未过期、未purge、未被过滤。
不能直接用 Binlog 恢复单行误删数据，必须配合全量备份 + Binlog 增量回放，且 DELETE 语句本身会被完整记录——你得先确认它没被覆盖、没被 purged、也没在 row 格式下被过滤掉。
Binlog 里到底有没有那条 DELETE 记录
MySQL 的 Binlog 不存储“删除前的数据”，只记录操作事件。如果你用的是 ROW 格式（推荐且默认），DELETE 会记下被删行的完整快照（即“before image”）；如果是 STATEMENT 格式，则只记 DELETE FROM t WHERE id = 123 这条语句——万一 WHERE 条件不唯一或表结构已变，重放可能删错行。
- 检查当前格式：
SHOW VARIABLES LIKE 'binlog_format'; - 确认目标事务是否还在可用 Binlog 文件中：
SHOW BINLOG EVENTS IN 'mysql-bin.000005' LIMIT 20;，找Delete_rows事件 - 别忘了 Binlog 可能已被
expire_logs_days自动清理，或被PURGE BINARY LOGS手动删掉
从 Binlog 提取并反转 DELETE 为 INSERT
ROW 格式下，可以用 mysqlbinlog 解析出被删行的原始值，再手动生成对应 INSERT 语句。这不是自动恢复，而是“人工捞数据”。
- 定位事件位置：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000005 | grep -A 20 'Delete_rows' - 加
--skip-gtids和--exclude-gtids避免 GTID 冲突（尤其在主从环境） - 输出里看到类似
### DELETE FROM `test`.`t`### WHERE### @1=123 ### @2='abc'，这就是你要还原的行 - 注意：如果表有自增主键、时间戳默认值、触发器或生成列，原样 INSERT 可能失败，得手动补全或调整字段
为什么不能跳过全备直接“回滚 Binlog”
Binlog 是追加日志，不是快照。它不包含表的初始状态，也没有事务级的“反向操作”机制。单独回放某段 Binlog，可能把其他正常写入也一并重放，导致数据重复或错乱。
- 标准流程是：
restore full backup → apply binlog from backup time to just before DROP/DELETE - 如果你没定期全备，又没开
binlog_row_image=FULL（默认就是 FULL），某些 UPDATE/DELETE 可能只记录变化列，缺失完整行像 - 用
mysqlbinlog --stop-datetime或--stop-position截断回放很关键，多一秒就可能越过误操作点
真正实用的补救路径
线上误删后第一反应不该是翻 Binlog，而是立刻停写、确认备份有效性、评估业务容忍窗口。Binlog 恢复本质是“重建+重放”，不是“撤销”。
- 紧急只读锁定表：
FLUSH TABLES t WITH READ LOCK;（注意锁粒度和影响） - 验证最近一次
xtrabackup或mysqldump --single-transaction是否可用，时间点是否早于误删 - 若只有 Binlog 无全备，可尝试用
mysqlbinlog导出全部 DML 到 SQL 文件，人工删掉误删语句及其后续依赖变更，再导入空库——但需严格测试，不可直连生产 - 最易忽略的一点：
binlog_format在会话级可能被临时改过，而mysqlbinlog默认不显示 SET 语句上下文，容易误判事件格式
