必须提前开启binlog且设为row格式,否则无法恢复单条误删数据;需确认log_bin=on且binlog_format=row,再通过mysqlbinlog定位delete_rows_event提取字段值构造insert语句。

必须提前开启 binlog 且设为 ROW 格式,否则误删后根本没法恢复单条数据——不是操作不会,是日志里压根没存那行被删了什么。
确认当前 MySQL 是否满足恢复前提
先连上 MySQL,执行这两条命令:
SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format';
如果 log_bin 是 OFF,或 binlog_format 不是 ROW,那就别往下试了——你只能从备份还原整库,binlog 恢复这条路走不通。
-
log_bin=ON是硬性门槛,没开就等于没录像机 -
binlog_format=ROW才能记录每行被删前的完整镜像;STATEMENT只记DELETE FROM t WHERE id=123这种语句,删错条件时完全无法定位真实影响行 - 云数据库(如阿里云 RDS)可能默认开
ROW,但得确认 binlog 开启时间早于误删时间,否则那段日志根本不存在
配置 binlog 需要改 my.cnf 并重启
编辑 MySQL 配置文件(通常是 /etc/my.cnf 或 /etc/mysql/my.cnf),在 [mysqld] 段下添加:
[mysqld] log-bin=mysql-bin server-id=1 binlog_format=ROW
注意:
-
server-id必须设,哪怕单机也要唯一,否则某些工具(如mysqlbinlog)解析会出问题 - 不要加
binlog-do-db这类过滤项,它会漏掉跨库操作,导致恢复不全 - 改完必须重启 MySQL:
systemctl restart mysqld(CentOS)或service mysql restart(Ubuntu) - 重启后立刻执行
SHOW MASTER STATUS;确认新 binlog 文件已生成,且Position不是 0
用 mysqlbinlog 定位并提取被删行的镜像
ROW 格式下,删除操作会以 Delete_rows_event 形式记录,里面含被删行所有字段值——这才是能反向构造 INSERT 的依据。
先查最近的 binlog 文件:
SHOW BINARY LOGS;
再用 mysqlbinlog 解析(关键参数不能少):
mysqlbinlog --base64-output=DECODE-ROWS -v \ --start-datetime="2026-10-01 19:00:00" \ --stop-datetime="2026-10-01 19:05:00" \ /var/lib/mysql/mysql-bin.000005 > del_event.txt
在输出里找 Delete_rows_event 块,它下面的 ### DELETE FROM `db`.`table` 后面跟着的就是被删行的字段和值,例如:
### SET ### @1=123 ### @2='alice' ### @3=1
对应就能写出还原 SQL:INSERT INTO `db`.`table` VALUES (123, 'alice', 1);
- 时间范围尽量窄,避免解析几 GB 日志;不知道时间就用
SHOW BINLOG EVENTS IN 'mysql-bin.000005' FROM 12345逐段查位置 - 别直接执行解析出的原始 SQL,里面混着
BEGIN/COMMIT和其他事务,只取Delete_rows_event对应的字段部分 - 生产环境务必先在测试库验证还原语句,避免把同主键数据重复插入导致报错
恢复时最容易被忽略的三个点
很多人卡在这三步上,不是不会查,是没意识到它们必须做:
- 误删后立刻停写:新数据写入会覆盖旧 binlog 文件,或让后续解析更难区分“误删”和“正常变更”
- 别用
mysqlbinlog --database过滤表名:它只过滤 Query 事件,对Delete_rows_event无效,照样会把其他表的变更混进来 - 还原 INSERT 语句里字段顺序必须和表定义一致:
mysqlbinlog输出的@1,@2对应建表时的列序,不是 SELECT 出来的顺序











