如何通过MySQL binlog二进制日志恢复误删的单条数据？-mysql教程-PHP中文网

必须确保binlog开启且格式为row，否则无法精准恢复单条误删数据；通过mysqlbinlog定位delete_rows_event获取被删行镜像，构造insert语句还原，并在安全环境下执行以避免重复删除。

如何通过mysql binlog二进制日志恢复误删的单条数据？

确认 binlog 是否开启且格式为 ROW

MySQL 默认不开启 binlog，或者开启后格式是 STATEMENT，这两种情况都无法精准恢复单条误删数据。binlog_format=ROW 是前提，否则 DELETE 语句在 binlog 中只记录 SQL 文本，看不到被删的具体行内容。

执行以下命令验证：

SHOW VARIABLES LIKE 'log_bin';<br>SHOW VARIABLES LIKE 'binlog_format';

如果 log_bin 是 OFF，或 binlog_format 不是 ROW，那就无法通过 binlog 恢复单条数据——只能从备份还原整库或整表。

修改配置需重启 MySQL，且必须在误操作前生效，事后补救无效
ROW 格式会显著增大 binlog 体积，尤其对大字段或批量操作，需权衡磁盘与恢复能力
部分云厂商（如阿里云 RDS）默认开启 ROW 格式，但需确认 binlog 开启时间早于误删时间

定位误删语句对应的 binlog 事件位置

用 mysqlbinlog 解析日志，关键不是找 DELETE 语句本身，而是找到它对应的 Write_rows_event 或 Delete_rows_event ——因为 ROW 格式下，删除动作会以“删除前的完整行镜像”形式记录在 Delete_rows_event 中。

示例命令（按时间范围缩小搜索）：

mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-05-20 14:20:00" --stop-datetime="2024-05-20 14:25:00" /var/lib/mysql/mysql-bin.000003

输出中重点识别：

包含 ### DELETE FROM `db`.`table` 的块
紧随其后的 ### @1=... @2=... 行 —— 这就是被删数据的原始值（@1 是第一列，依此类推）
注意 server id 和 end_log_pos，用于后续精确截取

容易踩的坑：--base64-output=DECODE-ROWS 缺失会导致看到一堆 BINLOG '...' 编码，根本没法读；-v 必须加，否则不显示 row event 内容。

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

提取并构造 INSERT 语句还原数据

binlog 中的 Delete_rows_event 记录的是删除前的行，所以直接把它“反向”转成 INSERT 即可。但不能手敲，要严格对齐字段顺序、类型和 NULL 处理。

推荐做法：用 mysqlbinlog 输出 SQL 片段，再人工替换 DELETE 为 INSERT，并补全字段名：

### DELETE FROM `test`.`user`<br>### WHERE<br>###   @1=1001<br>###   @2='alice'<br>###   @3=NULL

→ 改写为：

INSERT INTO `test`.`user` (id, name, email) VALUES (1001, 'alice', NULL);

字段名必须查表结构：DESCRIBE test.user;，不能靠猜测
遇到 @3=NULL 要写成 NULL，不是字符串 'NULL'
时间类型（如 datetime）在 binlog 中可能显示为 @4=1716214800（Unix 时间戳），需转换回 '2024-05-20 14:20:00'
避免直接执行还原语句到线上库，先在测试库验证语法和逻辑