mysql误执行delete语句如何回滚_使用binlog2sql工具解析逆向SQL-mysql教程-PHP中文网

不能回滚。mysql未开启事务直接执行delete时，语句自动提交，rollback无效；唯一恢复方式是依赖row格式的binlog，通过binlog2sql生成反向insert语句恢复数据。

mysql误执行delete语句如何回滚_使用binlog2sql工具解析逆向sql

MySQL没开事务直接delete，还能回滚吗

不能。InnoDB 表执行 DELETE 时若不在显式事务中（即没写 BEGIN 或 START TRANSACTION），语句一提交就永久生效，ROLLBACK 无效。这时候唯一靠谱的恢复路径是依赖 binlog —— 前提是 MySQL 确实开启了 binlog，且格式为 ROW（STATEMENT 格式无法还原具体行数据）。

确认 binlog 是否可用及格式是否正确

先连上 MySQL，检查关键配置：

SHOW VARIABLES LIKE 'log_bin';        -- 必须为 ON
SHOW VARIABLES LIKE 'binlog_format';   -- 必须为 ROW
SHOW VARIABLES LIKE 'server_id';       -- 必须非 0，且全局唯一

常见坑：

log_bin 显示 OFF：说明根本没开 binlog，工具无用武之地
binlog_format 是 MIXED 或 STATEMENT：binlog2sql 可能解析出空结果或错误 SQL，因为只靠 ROW 格式才能拿到被删行的完整前镜像（before_image）
binlog 文件已被 expire_logs_days 清理，或手动 PURGE BINARY LOGS 过：得先找最近的备份 + binlog 增量组合恢复

用 binlog2sql 提取 delete 对应的反向 insert

binlog2sql 的核心能力是把 ROW 格式 binlog 中的 DELETE_EVENT 翻译成等价的 INSERT 语句。操作分三步：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

定位误删时间点：用 mysqlbinlog --base64-output=decode-rows -v 扫一遍 binlog，找到含 DELETE FROM `db`.`table` 的位置和 timestamp
生成逆向 SQL：python binlog2sql.py -h127.0.0.1 -P3306 -uuser -p'pwd' -dtest -tstudent --start-file='mysql-bin.000001' --start-datetime='2024-05-20 10:30:00' --stop-datetime='2024-05-20 10:35:00' -B，其中 -B 表示输出回滚语句（即 INSERT）
注意过滤条件：--only-dml 避免混入 DDL；--no-primary-key 慎用，它会让生成的 INSERT 缺少主键，可能引发重复冲突

典型输出形如：INSERT INTO `test`.`student`(`id`, `name`, `age`) VALUES (101, 'Alice', 22); —— 这就是你要执行的“救命 SQL”。

执行恢复前必须验证和隔离

直接在原库跑 INSERT 很危险，尤其当表有自增主键、唯一索引或触发器时：

先在测试库或临时库中 source 生成的 SQL，看是否报错（比如主键冲突、字段类型不匹配）
如果原表有 ON DELETE CASCADE 外键，binlog2sql 不会自动还原关联表，得人工补全
避免覆盖后续写入：确认 --stop-datetime 严格卡在误删之后、其他业务写入之前；否则可能把别人新插的数据又删掉一遍
生产环境务必用 INSERT IGNORE 或 REPLACE INTO 替代原始 INSERT，防止主键重复中断恢复

最易被忽略的一点：binlog 中的 DELETE 事件不包含事务提交时间戳，只记录 event 自身时间。如果误删前后有高并发写入，--start-datetime 和 --stop-datetime 的边界必须结合 mysqlbinlog 输出的 ### 注释行逐行比对，不能只信日志文件名或大致时间。