必须提前开启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 出来的顺序
