干过数据库运维的人，谁还没个手抖的时刻呢？敲错一条delete语句，没加where条件，或者少了个limit，几百万条数据瞬间蒸发。更狠的是，truncate table或者drop table，连后悔的机会都不给。这时候心跳加速、手心冒汗都很正常。但别慌，MySQL其实留了好几扇后门，只要动作快、方法对，大部分情况下数据都能找回来。
先说最常用的招数：binlog。只要你的MySQL开启了binlog（二进制日志），就等于给每一次数据变更上了保险。binlog默认是不开的，很多开发环境图省事没开，但生产环境基本都会开。你可以用这个命令行工具，把binlog文件解析成SQL语句。具体操作是：先找到误删的时间点，然后用把这段时间的日志导出来。接着用grep或者sed过滤掉delete语句，只保留insert，再重新执行一遍。注意，这里有个坑：如果你误删后马上有大量新数据写入，binlog里会混着其他操作，提取的时候要格外小心。最好先把表结构备份好，然后在一个干净的数据库里回放，确认没问题再导入原库。
如果binlog没开，或者binlog文件已经被覆盖了，那就得靠数据库的物理备份了。大多数公司都有定时备份策略，比如每天凌晨用mysqldump或者XtraBackup全量备份一次。这时候你需要找到最近一次完整备份的文件，把它恢复到一台临时服务器上。假设你用的是mysqldump生成的SQL文件，直接就行。但问题是，备份时间点到误删时间点之间还有数据差异，这部分数据丢了怎么办？有两种处理方式：一是如果你同时还有binlog，可以把备份时间点到误删时间点之间的binlog也提取出来，增量恢复到临时库，再把临时库里的数据导回原库；二是如果只有备份没有binlog，那就只能接受数据丢失的事实，从备份里找回大部分数据，损失的那部分靠业务日志或者人工补录。
说到XtraBackup，这是Percona公司出品的物理备份工具，比mysqldump快得多，尤其适合大库。它做的是物理级别的文件拷贝，备份出来的是数据文件。恢复的时候需要先把日志应用完，然后再把数据文件拷贝回MySQL的数据目录。很多人觉得物理备份恢复起来麻烦，其实不然。关键在于你要提前演练，别等出事了才翻文档。我见过一个运维大哥，每季度都会在测试环境模拟一次误删恢复，从解压备份到重新上线，全程计时不超过20分钟。这习惯值得学。
还有一个冷门但好用的工具：Flashback。这是阿里开源的binlog回滚工具，专门针对误操作设计的。原理很简单：它读binlog，把delete语句反向生成insert，把insert反向生成delete，把update反向生成相反的update。你只需要指定数据库名、表名、时间范围，它自动帮你生成回滚SQL。安装也不复杂，下载源码后用Go编译一下就行。用法是，然后它会输出一个binlog文件，再用解析就能得到回滚SQL。不过要注意，Flashback对MySQL 5.6及以下版本支持不太好，新版MySQL用row格式的binlog时效果最好。如果你的binlog是statement格式，那就别指望它了，老老实实手动解析吧。
万一以上手段都失灵了，比如备份也坏了、binlog也过期了，那就只能祭出最后的底牌：系统底层的文件恢复。MySQL的数据文件放在数据目录里，默认是/var/lib/mysql。如果表用的是InnoDB引擎，每个表对应一个.ibd文件。误删表数据后，只要操作系统没有把这块磁盘空间覆盖掉，理论上可以用dd或者testdisk这类工具把文件碎片捞回来。但实际操作难度极高，因为MySQL的缓存机制和操作系统文件系统之间有个时间差，你删了数据，InnoDB可能只是标记了回收，真正的磁盘空间还没释放。不过有个前提：你得立刻停止MySQL服务，防止任何写入操作覆盖数据页。然后把数据目录所在的磁盘做成只读挂载，再用extundelete或者PhotoRec扫描。我亲眼见过一个案例，有人用PhotoRec从一块SSD上捞回了三天前误删的.ibd文件，恢复成功率大概六成。但注意，SSD有TRIM机制，一旦执行了删除操作，主控芯片可能马上擦除物理块，那就彻底没戏了。
说点扎心的实话：数据恢复成功率高不高，取决于你平时有没有做好防护。比如，给线上数据库开binlog，设置合理保留时间（至少7天），定期做全量备份并测试恢复，给重要操作加上参数提示确认，甚至在MySQL里开启sqlsafe_updates模式，强制delete和update必须带where条件。还有一个很多人忽略的点：给数据库账号做权限分级。开发人员只给读写权限，DML操作必须经过审计，truncate和drop权限只保留在管理员手里。我见过最离谱的事故是一个实习生用Navicat连了生产库，本来想清空测试表，结果手滑点到了生产表，直接truncate。还好备份够新，binlog保留周期是72小时，花了40分钟才恢复完。事后复盘发现，这个实习生压根没有truncate权限，是运维图省事，把所有账号都给了超级权限。所以，别马虎。
数据误删这件事，每个DBA都会遇到，关键是怎么应对。记住一条原则：先停写、再备份、后恢复。出事后第一时间把当前状态dump下来作为证据，然后再开始操作。千万别慌，MySQL的恢复手段远比你想象的多。只要binlog在，备份在，数据就还有救。哪怕什么都没有，只要磁盘没被覆盖，也有一线希望。但最好的恢复，永远是没发生过误删。与其事后手忙脚乱，不如平时多花点心思在备份和权限上。毕竟，数据是公司的命，你手里的活比你想的更重要。
