搞数据库的人，谁还没个手滑的时候？我刚入行那会儿，半夜两点多，一个drop table命令敲下去，整张业务表瞬间没了。当时后背直接冒冷汗，心跳比服务器风扇还快。这事过去好几年了，但每次想起来，那种绝望感还特别清晰。MySQL数据误删，说大不大，说小不小，关键看你有没有提前做准备。今天就跟大伙儿聊聊，真碰上这事，怎么把损失降到最低。
先说最理想的情况——你有完整的备份。很多公司每天凌晨跑一次全量备份，再配合binlog做增量备份。如果误删发生在早上十点，那恢复流程其实很清晰：先拿昨天凌晨的全量备份恢复出一个临时库，然后再把今天凌晨到误删时刻之间的binlog回放进去。这里有个坑：千万不能直接在生产库上操作，得单独搞一台机器或者同一个实例下新建一个库，等数据确认完整了再导回去。我见过有人图省事，直接在原库上覆盖恢复，结果binlog回放时又把其他表搞乱了，只能从更早的备份重新来，白白多花了两个小时。
如果没有全量备份，但开启了binlog，也不是完全没救。binlog里记录着所有数据变更操作，包括删表、删行。这时候需要用到mysqlbinlog工具，把binlog文件解析成SQL语句，然后找到误删操作之前的位置，把后面的语句重新执行。听起来简单，实操起来特别折磨人。binlog文件动辄几个G，解析出来几十万行SQL，你得一行行翻，找到那个该死的drop table或者delete from。我习惯的做法是先用grep定位到操作时间点附近的日志，再用sed截取出来。另外，binlog默认是ROW格式，解析出来的SQL可读性很差，得加上--base64-output=DECODE-ROWS和-v参数才能看到具体内容。
说到binlog，还有个容易被忽略的点：expirelogsdays这个参数。很多DBA觉得默认7天够了，但真碰上节假日或者项目冲刺期，等到发现问题时，binlog可能已经被自动清理了。我建议至少保留14天，有条件的话可以保留30天。另外，binlog文件最好单独挂载一块磁盘，别跟数据文件混在一起。万一磁盘坏了，数据和日志一起丢，那就真是叫天天不应了。我认识一个同行，他们公司就因为binlog和数据放在同一个RAID组里，磁盘故障后两边都恢复不了，只能从磁带里找一个月前的备份。
再说个更实用但很多人不知道的技巧：利用MySQL的延迟复制。简单说，就是搞一台从库，让它比主库慢一个小时或者更长时间同步数据。这样主库上误删了数据，从库上还没执行这个操作，你可以直接从从库里把数据捞出来。这个方案的好处是不用折腾binlog，也不用担心备份文件损坏。代价就是多耗费一台机器的资源，但对核心业务来说，这点成本完全值得。我经手的项目中，凡是上了延迟复制的，恢复时间基本都能控制在15分钟以内，比从头恢复备份快了两个数量级。
如果以上方法都行不通，比如备份文件损坏、binlog被清空、从库也同步了误删操作，那就只能走一步了——找专业的数据恢复公司。他们通常会用文件系统级别的工具，扫描磁盘上未被覆盖的数据页，尝试从中提取表结构和记录。这个方案有两个问题：一是贵，动辄几万块钱起步；二是成功率不是100%，取决于误删后磁盘有没有被写入新数据。我见过最惨的一个案例，某公司误删了核心数据库，又因为不懂，直接在原库上重建表重新写入，导致原始数据页被覆盖，花了八万块只恢复了六成数据。
聊了这么多技术手段，其实最关键的还是预防。我强烈建议每个MySQL实例都开启sqlsafeupdates参数，这个参数会强制要求delete和update语句必须带where条件或者limit限制。虽然有时候会误伤正常的全表更新操作，但总比手滑清空整个表强。另外，生产环境永远不要直接用root账号操作，给不同的人分配不同权限，删除表的权限只给少数几个人。我见过最夸张的一次事故，实习生用root账号连生产库，想在自己的测试表上做实验，结果连错了库，把用户表删了。事后复盘发现，他根本不应该有生产库的删除权限。
说个真事。有个朋友的公司，某天半夜被运维电话吵醒，说核心库的订单表被人误删了。他当时正在外地出差，只能远程指挥。先查备份，发现全量备份已经连续三天失败，因为磁盘空间不够，备份脚本自动跳过了。再查binlog，发现保留时间设置的是3天，而这张表上次修改是5天前，binlog已经被清掉了。没办法，只能用文件系统工具扫描磁盘，折腾了一整夜，总算把大部分数据捞回来了。但第二天业务还是受到了影响，因为恢复出来的数据中，有几百条订单的状态字段是乱的，只能人工逐条核对。这事之后，他给全公司的数据库都加上了延迟复制，并且把备份报警改成了即时通知。
说一千道一万，数据恢复这件事，功夫在平时。别等到真出了事，才想起来检查备份是否完整、binlog是否开启、权限是否合理。我见过太多人，平时觉得这些配置太麻烦，或者觉得“我不会那么倒霉”，结果真碰上了，代价往往是当初省下那点时间的几百倍。如果你现在就去检查一下自己负责的MySQL实例，把备份策略、binlog保留时间、延迟复制这些基础配置都过一遍，那这篇文章就没白写。
