MySQL binlog不支持直接回滚DELETE，需基于ROW格式和FULL行镜像解析生成逆向INSERT语句；官方mysqlbinlog无原生回滚功能，须借助pt-flashback、binlog2sql等工具或手动重写逻辑，并验证结构、外键与数据一致性。
MySQL binlog 里没有直接的 DELETE 回滚机制
MySQL 本身不支持像 Oracle 那样的闪回（flashback）功能，DELETE 语句一旦提交，数据就从 InnoDB 页面上被标记为可复用，不是“立刻物理删除”，但也不再能通过标准 SQL 恢复。靠 binlog 回滚，本质是解析日志、逆向生成 INSERT 语句——这需要日志格式为 ROW，且未开启 binlog_row_image=MINIMAL（否则缺失完整前镜像）。
常见错误现象：mysqlbinlog --base64-output=decode-rows -v 解析出的 event 显示 ### DELETE FROM `db`.`t1` ### WHERE @1=1，但没看到 @2@3 等字段值——说明 binlog 没记录完整行数据，flashback 工具会失败。
- 确认 binlog 格式：
SHOW VARIABLES LIKE 'binlog_format';必须是ROW - 检查行镜像级别：
SHOW VARIABLES LIKE 'binlog_row_image';推荐FULL，MINIMAL会导致 flashback 插件无法还原被删行 - 确保误删后没执行过
FLUSH LOGS或重启 mysqld，否则可能丢失关键 binlog 文件
使用 percona-toolkit 的 pt-flashback 处理 DELETE
pt-flashback 是目前最稳定、无需安装 MySQL 插件的命令行工具，它不依赖 MySQL 服务端扩展，只读取本地 binlog 文件并输出可执行的 INSERT 语句。
典型使用流程：
- 先定位误删时间点或 binlog 位置：
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000001 | grep -A 5 -B 5 "DELETE FROM `mydb`.`users"` - 提取起止 position：
mysqlbinlog --base64-output=decode-rows -v --start-position=1234 --stop-position=5678 mysql-bin.000001 > /tmp/del_event.log - 生成回滚 SQL：
pt-flashback --binlog-dir=./ --base64-output=decode-rows --start-position=1234 --stop-position=5678 --database=mydb --table=users > rollback.sql
注意：pt-flashback 默认只处理 DELETE 和 UPDATE，对 TRUNCATE 或 DROP 无效；它不会自动加事务或 SET SQL_LOG_BIN=0，生成的 rollback.sql 需人工审核后再执行。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
为什么不要直接用 mysqlbinlog + sed 手动逆向
有人尝试用 mysqlbinlog --base64-output=decode-rows -v 输出后，用 sed 把 DELETE 替换成 INSERT，再调换 WHERE 和 VALUES。这种做法在简单单表、无 NULL/LOB/BLOB 字段时可能凑效，但极易出错：
- 遇到
TIMESTAMP字段，binlog 中可能记录的是@3=NULL，但实际表定义允许DEFAULT CURRENT_TIMESTAMP，手动替换会插入NULL导致报错 -
ENUM或SET类型在 binlog 中以数字形式出现（如@2=1），而原值可能是'on'，sed无法映射 - 如果
DELETE带WHERE条件（非全表删），mysqlbinlog输出里只有WHERE子句，没有被删行的完整值——根本没法反推INSERT
也就是说，只有 ROW 格式 + FULL 镜像 + 全表 DELETE 这三个条件同时满足时，“手写逆向”才勉强可行；其他情况几乎必然丢数据或报错。
flashback 插件（如 binlog2sql、mysqlbinlog_flashback）的兼容性陷阱
社区有基于 Python 的 binlog2sql、Go 写的 mysqlbinlog_flashback 等工具，它们封装了更友好的 CLI，但底层仍依赖 binlog 解析逻辑。容易被忽略的关键点：
-
binlog2sql要求 MySQL 用户有REPLICATION SLAVE和REPLICATION CLIENT权限，且必须能连上目标实例读取information_schema.COLUMNS——若误删发生在已下线的旧实例上，它就完全不可用 - 所有这类工具都无法处理
GTID模式下跨多个 binlog 文件的事件拼接（比如一个事务横跨mysql-bin.000001和mysql-bin.000002），必须人工合并文件或指定完整 GTID 范围 - 如果表用了
COMPRESSED行格式或启用了page_compression，部分工具解析ROWevent 时会跳过字段或报Unknown packet type
真正关键的不是选哪个工具，而是确认 binlog 是否具备完整前镜像、是否能访问到对应时刻的表结构、以及被删数据是否已被 purge 线程清理（innodb_purge_threads > 0 且长时间未刷脏页时，有可能）。这些细节比工具命令多敲几个参数重要得多。
