binlog是MySQL误删数据后唯一靠谱的恢复途径，需确保log_bin=ON、binlog_format=ROW且日志未过期；通过mysqlbinlog定位误删事件，再生成INSERT或跳过重放恢复。
MySQL 误删数据后，binlog 是唯一靠谱的恢复途径
没有开启 binlog 的 MySQL 实例，误删后基本只能靠备份还原——而备份往往滞后、不全、甚至根本没做。只要 binlog_format = ROW 且日志未过期，就能精准定位并回放/跳过那条 DELETE。别信“闪回工具一键恢复”，底层全是解析 binlog，自己动手更可控。
确认 binlog 是否可用及位置
先连上数据库执行：SHOW VARIABLES LIKE 'log_bin'; 返回 ON 才行；再查日志列表：SHOW BINARY LOGS; 看最近的文件名（如 mysql-bin.000012）和大小。重点检查：
• expire_logs_days 是否太小（默认 0 表示永不过期，但很多运维会设成 7）
• max_binlog_size 是否导致日志轮转太快，误删操作被挤出最老文件
• 如果用的是 RDS（如阿里云、腾讯云），需确认是否开启了「Binlog 下载」权限或「日志保留天数」配置
用 mysqlbinlog 解析出误删语句的精确位置
别直接用 mysqlbinlog --base64-output=DECODE-ROWS -v 全量看——大库日志动辄 GB，肉眼根本找不到。正确做法是：先估算误删时间点，用 --start-datetime 和 --stop-datetime 缩小范围；再 grep 关键字快速定位：
mysqlbinlog --base64-output=DECODE-ROWS -v \ --start-datetime="2024-05-20 14:22:00" \ --stop-datetime="2024-05-20 14:23:00" \ /var/lib/mysql/mysql-bin.000012 | grep -A 5 -B 5 "DELETE FROM `users`"
注意：
• ROW 格式下，实际删除的行内容在 ### DELETE FROM 后面的 ### WHERE 块里，不是 SQL 文本本身
• 时间范围宁宽勿窄，MySQL 写 binlog 的时间戳可能和你执行命令的时间有秒级偏差
• 如果误删发生在主从架构的从库，binlog 默认不记录（log_slave_updates=OFF），必须去主库查
生成反向 SQL 或跳过该事件重放
恢复分两种场景：
• 想把删掉的数据找回来 → 用解析出的 WHERE 条件，拼 INSERT 语句（注意字段顺序、NULL 值、时间戳等）
• 想跳过这次删除，让从库/新实例追上主库 → 记下该事件的 position（比如 end_log_pos 123456789），用 mysqlbinlog --stop-position=123456789 截断重放，再从下一条 position 继续
关键提醒：
• 不要用 mysqlbinlog --database 过滤库名，它只过滤 USE 语句，对 ROW 格式无效
• 回放前务必在测试库验证 SQL，特别是涉及自增 ID、外键、触发器时，INSERT 可能失败
• 如果误删后还执行了其他写操作，不能简单“倒带”，得人工判断依赖关系，否则可能破坏一致性
真正难的从来不是怎么解析 binlog，而是搞清那条 DELETE 到底影响了哪些行、有没有被后续 UPDATE 覆盖、以及业务侧是否已基于“空状态”做了新写入——这些没法靠工具自动判断。
