上周四晚上十一点，我刚洗完澡准备躺下，手机就炸了。群里一个哥们儿连发了十几个语音，声音都在抖：“完了完了，我把生产库的订单表给删了，老板明天要查上个月的销售数据。”我问他有没有备份，他说有，但备份是一个月前的。那一刻我隔着屏幕都能感受到他的绝望。这种事儿在互联网圈子里太常见了，谁还没手滑过呢？但问题是，手滑之后你能不能把数据捞回来，这才是真本事。
先说最基础的一招：利用MySQL自带的binlog。binlog这东西就像数据库的黑匣子，记录了你所有的写操作。只要你的MySQL开启了binlog（默认很多生产环境都是开的），理论上你可以把数据恢复到任意时间点。操作分三步：先找到误删前的那个时间点，然后用mysqlbinlog工具把binlog解析成SQL语句，把那些INSERT或者UPDATE语句挑出来重新执行。举个具体的例子，假如你上午十点误删了user表，那就用mysqlbinlog --start-datetime=“2024-01-01 09:00:00” --stop-datetime=“2024-01-01 10:00:00” /var/log/mysql/binlog.001 > recover.sql，从生成的SQL里找到你需要的语句。这里有个坑：如果你的binlog没开或者被自动清理了，那这条路就走不通了。
要是binlog这条道走不通，那就得看你的备份策略了。很多人以为有备份就万事大吉，其实不是。备份分全量备份和增量备份，全量备份比如mysqldump或者XtraBackup打出来的包，增量备份就是二进制日志。恢复的时候得先恢复全量备份，再回放增量日志。比如说你每周日做一次全量备份，周二下午三点误删了数据，那你就先恢复上周日全量备份，再回放周日到周二下午三点的binlog。这里有个容易翻车的地方：如果你恢复全量备份后又回放了所有binlog，那就会恢复到最新的状态，误删的数据已经被删除了。所以你得回放到误删前的那一秒，千万别多回放一秒。
还有一种情况比较头疼：表结构被改了。比如你先删了数据，然后又改了表结构，这时候直接回放binlog会报错，因为字段对不上。解决办法是先用FLASHBACK工具。MySQL官方没有自带的闪回功能，但社区有个叫binlog2sql的开源工具特别好使。它能从binlog里反向生成SQL，把DELETE变成INSERT，把UPDATE反向更新。安装也简单，pip install binlog2sql就行。用法：python binlog2sql.py --flashback -h127.0.0.1 -P3306 -u root -p‘密码’ -d 数据库名 -t 表名 --start-file=‘binlog.001’ --start-position=1000 --stop-position=2000 > rollback.sql。这个工具最牛的地方在于，它不需要你手动去翻binlog找SQL，直接给你生成回滚语句。
说到工具，不得不提Percona的XtraBackup。这玩意儿是全量备份的利器，支持热备，不锁表。很多DBA都用它做定期备份。但真正牛的是它的增量备份功能。比如你每天凌晨做一次全量备份，每两小时做一次增量备份。万一误删了数据，你只需要恢复最近一次全量备份，然后依次恢复增量备份，就能回到误删前的状态。操作命令：xtrabackup --target-dir=/backup/incremental --incremental-basedir=/backup/full。恢复的时候先用xtrabackup --prepare --apply-log-only --target-dir=/backup/full，再合并增量备份。这套流程虽然步骤多，但胜在稳定可靠，大厂都在用。
如果你手头没有任何备份，binlog也没开，那是不是就彻底没救了？别急，还有一招：从从库或者延迟库捞数据。很多公司为了高可用，会搭主从复制架构。从库的数据和主库是实时同步的，但主库误删数据后，从库也会跟着删。不过如果你配置了延迟复制，比如设置了延迟1小时同步，那从库里还保留着1小时前的数据。这时候直接从从库导出一份数据，再导入主库就行。命令：mysqldump -h从库IP -u root -p 数据库名 表名 > recover.sql，然后 mysql -h主库IP -u root -p 数据库名 < recover.sql。这个操作需要你在配置主从时就设置好延迟参数CHANGE MASTER TO MASTER_DELAY=3600，不然后悔都来不及。
说几个血的教训。第一，恢复数据前一定要先备份当前的binlog，防止操作过程中又产生新的数据。第二，恢复操作要在测试环境先演练一遍，别直接在线上跑，特别是大表。第三，恢复完成后要立即检查数据完整性，比如主键有没有重复、外键约束有没有被破坏。我之前见过一个案例，有人恢复数据后没检查，结果因为自增主键冲突，导致新插入的数据全报错。第四，把恢复脚本和步骤写成文档，贴在团队wiki里。别觉得自己记性好，半夜两点被叫起来恢复数据的时候，脑子是宕机的。记住，数据恢复不是炫技，是保命的技能。你永远不知道下一次手滑会在什么时候发生。
