MySQL 5.7 可通过 ROW 格式 binlog 精准恢复误删行级数据，前提是 log_bin=ON、binlog_format=ROW、日志未过期；TRUNCATE/DROP 无法恢复，必须依赖备份。
只要 binlog 已开启、格式为 ROW、且对应日志未被清理，MySQL 5.7 就能精准恢复误删的行级数据——不需要备份，也不依赖第三方工具。
确认 binlog 是否可用：三个必须同时满足的条件
恢复失败，90% 是卡在这一步。别跳过检查，直接执行命令验证：
-
SHOW VARIABLES LIKE 'log_bin';—— 必须返回ON，OFF表示完全不可用 -
SHOW VARIABLES LIKE 'binlog_format';—— 必须是ROW，STATEMENT或MIXED无法还原被删的具体行 -
SHOW VARIABLES LIKE 'expire_logs_days';或（MySQL 8.0+）binlog_expire_logs_seconds—— 确保数值大于误删发生距今的天数，否则日志已被自动 purge
注意：log_bin 是只读变量，SET GLOBAL log_bin = ON 会报错。必须改配置文件 my.cnf，加 log_bin=mysql-bin 并重启 mysqld。
定位误删操作在哪个 binlog 文件和位置
不要靠猜时间，先缩小范围再精确查找。顺序不能乱：
- 运行
SHOW BINARY LOGS;查看所有 binlog 文件及文件大小，结合误删时间，挑出最可能包含操作的 1–2 个文件（如mysql-bin.000123） - 用
mysqlbinlog解析该文件，加上--base64-output=decode-rows -vv才能看到被删行的原始值；例如：mysqlbinlog --base64-output=decode-rows -vv /var/lib/mysql/mysql-bin.000123 | grep -A 10 -B 5 "DELETE FROM users" - 如果知道大概时间，优先用时间过滤：
mysqlbinlog --start-datetime="2026-08-12 14:20:00" --stop-datetime="2026-08-12 14:25:00" --base64-output=decode-rows -vv /var/lib/mysql/mysql-bin.000123 > /tmp/del_events.sql
关键点：ROW 格式下，DELETE 事件里会明确写出被删行的 @1=123 @2='alice' @3=28 这类字段值，这才是可恢复的依据。
生成并执行逆向 INSERT 恢复语句
不能直接把 binlog 里的 DELETE 语句复制回来执行，必须反转成 INSERT。手动写容易漏字段或类型错位，推荐两种方式：
- 用
mysqlbinlog输出带注释的 SQL，人工提取字段名和值，拼成标准INSERT INTO table (col1,col2) VALUES (val1,val2);—— 适合少量行、表结构简单 - 用开源小工具
binlog2sql（Python 写）自动生成逆向语句：python binlog2sql.py -h127.0.0.1 -P3306 -uuser -p'pwd' -dmydb -tusers --start-file='mysql-bin.000123' --start-pos=123456 --stop-pos=123999 --flashback > rollback.sql
其中--flashback参数会把DELETE自动转成INSERT
执行前务必先在测试库验证语句是否语法正确、字段顺序是否匹配，尤其是 TIMESTAMP、ENUM、JSON 类型字段容易出错。
TRUNCATE 和 DROP 表无法用此方法恢复
这是最容易忽略也最致命的边界情况：TRUNCATE TABLE users 和 DROP TABLE users 在 ROW 格式 binlog 中不记录任何行数据，只记 DDL 语句本身。它们清空或删除的是物理段，binlog 不保存“被删的每一行是什么”。此时唯一可行路径是：
- 从最近一次
mysqldump或xtrabackup备份中恢复整表 - 若无备份，且表刚被删，可尝试用
extundelete（Linux ext4）或photorec直接扫描磁盘文件系统——但这属于数据抢救范畴，成功率低、耗时长、需停服
真正关键的不是“怎么恢复”，而是“为什么没提前开 log_bin + ROW + 合理 expire_logs_days”——这个配置一旦漏掉，所有后续操作都失去意义。
