文档目标

不小心执行了 UPDATE 或 DELETE 误操作？别慌张，只要 binlog 采用的是 ROW 格式，再借助 my2sql 工具，就可以精准生成回滚 SQL 语句，将数据成功恢复。接下来这套流程，从定位 binlog 到执行数据恢复，每一步都会详细拆解说明。

第一部分：前置准备与 binlog 定位

1.1 确认 binlog 配置与状态

首先需要确认 MySQL 已开启 binlog 功能，并且格式为 ROW——这是整个数据恢复工作的前提条件。在客户端执行以下命令，检查三个关键变量：

SHOW VARIABLES LIKE 'log_bin';              -- 必须为 ONSHOW VARIABLES LIKE 'binlog_format';        -- 必须为 ROWSHOW VARIABLES LIKE 'log_bin_basename';     -- 获取 binlog 文件存储路径前缀

1.2 查看所有 binlog 文件

想要了解当前有哪些 binlog 文件可供使用？直接运行以下命令：

SHOW BINARY LOGS;

输出示例：

1.3 定位误操作时间对应的 binlog 文件

核心思路其实很简单：借助 mysqlbinlog 工具逐一检查每个文件的起止时间，找到覆盖误操作时间点（例如 2026-04-02 14:56:00 ~ 15:05:00）的那个文件。以下三种方法可供选择：

方法一：查看单个文件的起始时间

cd /d "D:basemysql8bin"mysqlbinlog --base64-output=decode-rows -vv "D:basemysql8DataDESKTOP-H12BE21-bin.000201" | findstr "Start time"

方法二：扫描文件中的具体时间戳

mysqlbinlog --base64-output=decode-rows -vv "D:basemysql8DataDESKTOP-H12BE21-bin.000201" | findstr "#230402"

输出结果中如果出现 #230402 14:56:23，就说明该文件包含了误操作对应的时间点。

方法三（推荐）：按时间范围批量扫描多个文件

mysqlbinlog --base64-output=decode-rows -vv --start-datetime="2026-04-02 14:50:00" --stop-datetime="2026-04-02 15:10:00" "D:basemysql8DataDESKTOP-H12BE21-bin.00020*" > D:binlog_scan.txt

这条命令会将所有以 .00020 开头的文件扫描一遍，把时间范围内的事件全部输出到文本中，结果一目了然。

1.4 快速判断技巧

• 文件大小：接近 1GB 的文件通常覆盖的时间段较长；几百 KB 的小文件时间范围则非常有限。
• 文件序号：序号越大（如 .000201），文件越新。误操作发生时间越近，就越应该优先检查序号较大的文件。
• 当前写入文件：执行 SHOW MASTER STATUS; 可以查看当前正在写入的 binlog 文件。

第二部分：使用 my2sql 生成回滚 SQL

2.1 环境准备

将确认好的 binlog 文件复制到 my2sql 工具所在的目录：

copy "D:basemysql8DataDESKTOP-H12BE21-bin.000201" D:my2sqlmy2sql-master

2.2 执行 my2sql 生成回滚 SQL

接下来就是核心环节——利用 my2sql 解析 binlog 并生成回滚语句。请注意提前下载好 Go 环境并完成 my2sql 源码的编译。

cd /d D:my2sqlmy2sql-mastermy2sql.exe -user root -password 123456 -host 127.0.0.1 -port 3306 -mode file -local-binlog-file DESKTOP-H12BE21-bin.000201 -start-file DESKTOP-H12BE21-bin.000201 -work-type rollback -start-datetime "2026-04-02 14:56:00" -stop-datetime "2026-04-02 15:05:00" -databases sm-server -tables order_ai_record -output-dir D:result

参数详解：

2.3 检查生成的回滚 SQL

• 打开 D:resultrollback.201.sql 文件。
• 确认内容是将 DELETE_FG 从 '1' 改回原值的 UPDATE 语句。
• 仔细检查是否存在语法错误或意外的操作。

第三部分：执行恢复与验证

3.1 执行回滚 SQL

mysql -u root -p123456 sm-server < D:resultrollback.201.sql

3.2 验证恢复结果

-- 检查误操作标记字段是否已成功恢复SELECT COUNT(*) FROM order_ai_record WHERE DELETE_FG = '1';-- 抽查特定记录SELECT * FROM order_ai_record WHERE ID = 11675;

第四部分：完整流程图

1. 确认 binlog 已开启且格式为 ROW   ↓2. 执行 SHOW BINARY LOGS 列出所有文件   ↓3. 使用 mysqlbinlog 扫描文件时间范围 → 定位误操作对应的 binlog 文件   ↓4. 将 binlog 文件复制到 my2sql 目录   ↓5. 使用 my2sql 生成回滚 SQL（指定 -work-type rollback 和时间范围）   ↓6. 检查生成的 rollback.xxx.sql 文件内容   ↓7. 执行回滚 SQL 恢复数据   ↓8. 通过查询验证数据是否恢复正确

第五部分：避免误操作的最佳实践

5.1 安全更新习惯（生产环境强烈推荐）

-- 1. 开启事务BEGIN;-- 2. 先查询影响范围SELECT * FROM order_ai_record WHERE ID = 11675;-- 3. 执行更新或删除操作UPDATE order_ai_record SET DELETE_FG = '1' WHERE ID = 11675;-- 4. 再次确认结果SELECT * FROM order_ai_record WHERE ID = 11675;-- 5. 确认无误后再提交COMMIT;-- 如果发现操作有误，立即回滚ROLLBACK;

5.2 其他建议

• 定期备份：结合 mysqldump 或 xtrabackup 进行全量备份。
• 权限控制：生产环境中的核心表应禁止直接执行 DELETE，只允许逻辑删除（例如 UPDATE DELETE_FG = '1'）。
• 操作审计：启用 MySQL 审计插件，记录所有高风险操作行为。

附录：常用命令速查表

注意：需要提前下载 Go 环境并完成 my2sql 源码的编译。