如何执行恢复被误删数据的查询_基于Binlog记录的SQL重放-phpMyAdmin-PHP中文网

能恢复，前提是开启binlog且日志未过期；需检查log_bin、binlog_format、expire_logs_days三项配置，并用mysqlbinlog精准定位delete事件及对应行值，恢复时设sql_log_bin=0、注意事务边界和字符集。

能恢复，但前提是 mysql 服务启用了 binlog，且被删数据对应的事务日志还没被自动清理（expire_logs_days 未过期），并且你有权限读取 binlog 文件或通过 mysqlbinlog 解析。没开 binlog 或已 purge，基本无解。

别猜，直接连上 MySQL 执行命令查：

SHOW VARIABLES LIKE 'log_bin'; —— 必须是 ON
SHOW VARIABLES LIKE 'binlog_format'; —— 推荐 ROW，STATEMENT 格式下部分 DELETE 可能无法精确定位行
SHOW VARIABLES LIKE 'expire_logs_days'; —— 若为 0 表示不自动清理，但磁盘空间可能已满导致旧日志被手动 purge 过

再补查一句：SHOW MASTER LOGS; 看当前有哪些 binlog 文件，对比删除时间是否还在列表里。

直接全量重放 binlog 会把后续所有操作也执行一遍，大概率出错。必须精准定位到那几条 DELETE 语句，并反向生成 INSERT。

先用 mysqlbinlog --base64-output=DECODE-ROWS -v 解析出带行事件的可读内容（-v 是关键，不然看不到改了哪些字段）
用 --start-datetime 和 --stop-datetime 按时间粗筛，再人工搜 DELETE FROM `your_table`
找到对应事件的 end_log_pos 和前一个 start_log_pos，用 --start-position/--stop-position 精确截取
注意：ROW 格式下实际恢复要靠解析 Write_rows_v1 事件里的 @1, @2 值，不能直接拿 SQL 回放 —— 那只是注释

示例片段（ROW 格式输出）：

### DELETE FROM `test`.`users`
### WHERE
###   @1=1001
###   @2='alice'
###   @3=25

这说明删的是主键为 1001 的那行，恢复时得手写 INSERT INTO `test`.`users` VALUES (1001, 'alice', 25);

很多人卡在这几步，不是技术不行，是细节漏了：

没关 sql_log_bin 就执行恢复 SQL —— 新增的 INSERT 又会被记进 binlog，形成循环写入，甚至触发主从冲突；执行前务必 SET sql_log_bin = 0;
忽略事务边界 —— 一个 DELETE 可能在大事务里，前后还有其他表操作；只抽一条语句回放可能导致数据不一致，建议按 GTID 或 transaction 单元整体分析
字符集不匹配导致乱码插入 —— 特别是含中文的字段，解析 binlog 时加 --charset=utf8mb4，恢复连接也要确认客户端编码和表定义一致

真正难的不是“能不能恢复”，而是从几十 GB 的 binlog 里准确定位那几行、还原出原始值、避开复制链路干扰——这些没法全自动，得人盯日志、对 schema、验数据。