凌晨两点，开发同事打来电话：刚才手滑把一张订单表的数据全删了。这种电话接过的人都知道，心脏会漏跳一拍。但慌也没用，MySQL误删数据并非不可挽回，关键看你之前做了哪些准备，以及事发后第一时间的操作。
方案一：通过binlog日志精确恢复
binlog是MySQL的事务日志，记录了所有数据变更操作。只要binlog是开启的，就能通过它回放指定时间段的数据。
操作步骤：先用show binary logs;查看当前binlog文件列表，再用mysqlbinlog工具解析日志内容，找到误删操作的位置点。然后指定起始和结束position，把这段日志重放到一个临时库中，确认数据无误后再导回生产库。
有个细节容易踩坑：binlog格式必须是ROW模式才能精确恢复单行数据。如果你的MySQL用的是STATEMENT模式，恢复粒度会粗很多。执行show variables like 'binlog_format';确认一下，如果还是STATEMENT，建议尽快改成ROW。
方案二：全量备份加增量日志组合恢复
这个方案的思路是先用最近一次全量备份恢复到一个时间点，再用binlog补上从备份点到误删前的数据。适合数据量较大、单靠binlog回放太慢的场景。
具体做法：把最近一次mysqldump或Percona XtraBackup的全量备份恢复到临时实例，然后从备份时刻的binlog位置开始，回放到误删操作前一个事务。这个方案的恢复精度取决于你的全量备份频率，建议至少每天一次全量备份。
方案三：使用第三方恢复工具
如果binlog没开、全量备份也没有，情况就比较被动了。这时可以尝试用Undrop for InnoDB这类工具直接从ibd文件中提取数据。原理是解析InnoDB存储引擎的数据页，把未被覆盖的旧数据捞出来。
这类工具成功率不是百分之百，能不能恢复取决于磁盘上那些数据页有没有被新数据覆盖。所以发现误删后，第一时间要停止对该表的写入操作，减少数据被覆盖的概率。
说到底，最好的恢复方案是预防。开启binlog、定期全量备份、做好数据迁移备份流程，这三件事做到位，误删之后你也能从容应对。