不能直接回滚，必须通过 binlog2sql 解析 row 格式日志生成 insert 语句恢复；前提为 log_bin=on、binlog_format=row，且需准确定位误操作时间或 position 范围，再用 -b 选项逆向生成 sql 并验证后执行。
不能直接回滚，必须靠 binlog2sql 解析 ROW 格式日志生成 INSERT 语句来“反向修复”。 MySQL 对 DELETE 或 UPDATE 语句默认自动提交，没开事务就执行，ROLLBACK 完全无效。这时候唯一能用的路径是：确认 binlog 开启且为 ROW 格式 → 定位误操作时间点对应的 binlog 文件 → 用 binlog2sql 提取并逆向生成 SQL。
确认 binlog 是否可用且格式正确
这是整个流程的前提，缺一不可。连不上或配置错，后面所有命令都白跑：
-
SHOW VARIABLES LIKE 'log_bin';必须返回ON，否则根本没日志可解析 -
SHOW VARIABLES LIKE 'binlog_format';必须是ROW；MIXED或STATEMENT无法还原具体行数据，binlog2sql会输出空或错误 SQL -
SHOW VARIABLES LIKE 'binlog_row_image';建议检查是否为FULL（虽然binlog2sql不强制要求，但MINIMAL可能导致字段缺失） -
SHOW VARIABLES LIKE 'server_id';必须是非 0 值，否则复制和部分工具行为异常 - 运行
SHOW BINARY LOGS;看文件列表，再结合mysqlbinlog --base64-output=decode-rows -v扫描时间戳，确认目标 binlog 文件未被PURGE BINARY LOGS清掉
用 binlog2sql 定位并提取 DELETE 对应的 INSERT 语句
核心是让 binlog2sql 把 DELETE_EVENT 翻译成等价的 INSERT。关键参数不能错：
- 加
-B（即--flashback）选项，这是生成回滚语句的开关；不加就只输出原始DELETE - 用
--sql-type DELETE显式限定类型，避免混入UPDATE或 DDL 干扰结果 - 时间范围尽量窄：
--start-datetime和--stop-datetime控制在误操作前后 2–5 分钟内，减少噪音 - 指定
--start-file和--stop-file比只靠时间更可靠，尤其当 binlog 切换频繁时 - 加上
--only-dml过滤掉CREATE/DROP等 DDL，防止恢复时建表失败打断流程
示例命令：
python binlog2sql.py \ -h127.0.0.1 -P3306 -uadmin -p'secret' \ -dmydb -tuser_info \ --sql-type DELETE \ --start-file=mysql-bin.000012 \ --stop-file=mysql-bin.000012 \ --start-datetime="2026-09-29 14:22:00" \ --stop-datetime="2026-09-29 14:23:30" \ -B --only-dml > rollback.sql
执行前必须验证生成的 SQL 是否安全
直接在原库执行 rollback.sql 是高危动作，常见翻车点：
- 主键冲突：
INSERT INTO ... VALUES (1, ...)若原表已存在 id=1 的新记录，会报Duplicate entry；建议先SELECT确认目标主键值当前不存在 - 自增主键错位：如果表有
AUTO_INCREMENT，插入后可能影响后续插入的 ID 分配，需评估是否要手动ALTER TABLE ... AUTO_INCREMENT = N - 外键约束：若被删行关联其他表（如
ON DELETE CASCADE），binlog2sql不会自动还原关联数据，得人工补全或临时禁用外键检查 - 字段类型/长度变更：如果误删后表结构被改过（比如某
VARCHAR(50)改成VARCHAR(20)），生成的 INSERT 可能因超长被截断或报错 - 务必先在测试库
source rollback.sql跑通，再上生产；哪怕只是临时搭建一个空库 + 相同表结构也比直接干更稳
binlog2sql 在 2026 年的真实适用边界
它现在不是“首选”，而是“兜底”。MySQL 8.0 已成主流，但 binlog2sql 最后更新是 2018 年，对 8.0 的 GTID、新权限模型、加密连接支持弱；遇到大 binlog（>500MB）解析极慢（实测比 my2sql 慢 60 倍以上）。如果你的环境是 5.7 且 binlog 量小，它够用；如果是 8.0 或日志文件动辄上 G，优先考虑 my2sql —— 它支持离线解析、完整 GTID 过滤、DML 统计，而且 2022 年后持续维护。别迷信“最熟的工具”，要看它今天还能不能扛住你的数据量和版本。
