做运维这行十年，最怕半夜手机响。上周凌晨两点，某电商平台的朋友打来电话，声音都是抖的——误执行了DELETE语句，订单表少了七万条记录。备份有，但恢复到昨天凌晨的，意味着这一天白干。这种事我见过太多，每次都想骂人：为什么总有人觉得数据库不会出事？
先说个扎心的事实：90%的数据丢失，都是人为操作。删表忘加WHERE条件、UPDATE写错范围、DROP前没确认库名，这些低级错误造成的损失，远比黑客攻击、硬盘损坏大得多。我自己就干过蠢事，在一台测试机上执行了生产库的清理脚本，还好当时只清了日志表。所以指南第一条：先别慌，深呼吸，你越冷静，数据回来的概率越大。
接下来判断情况。如果误操作刚发生，立即停掉所有写入操作——包括应用服务、定时任务、其他DBA的查询。数据库的MVCC机制会在undo表空间里保留旧版本数据，你停得越快，能抢救的越多。也别急着重启数据库，有些误删的数据还在内存或系统缓存里，重启反而把数据弄丢了。这时候打开另一个终端，查一下当前连接，把业务连接全部断掉，只留你一个管理通道。
然后翻备份。这里要理清概念：全量备份加上binlog增量，才是完整的恢复链条。很多人只做了全量备份，误删后恢复到一个旧时间点，中间的数据全丢，然后哭天喊地。正确做法是：先恢复最近一次全量备份，再用binlog把数据追到误操作发生前的那一秒。具体操作，拿MySQL举例，，这个命令能把日志里的操作回放到指定时间点。注意，binlog得开启，没开的话，这一段只能靠运气。
没有备份怎么办？或者备份也损坏了？别急着绝望。如果是InnoDB引擎，还有几根救命稻草。第一，查一下目录下的和，这些文件里可能还残留着被删除数据页的碎片。用命令暴力搜索，能捞出一些文本信息，虽然不完整，但关键字段可能还在。第二，如果表是独立表空间（innodbfilepertable=ON），该表的文件里可能还有未覆盖的旧数据。用这类工具扫描，有机会找回一部分行记录。这个方法我试过，找回率大概六成，字段类型越简单，成功率越高。
还有一种特殊情况：整库被DROP了。这时候如果开启了binlog，恢复流程是：先建一个空库，然后用把全量备份之后到DROP之前的binlog全部重放。但有个坑——如果DROP操作本身也写进了binlog，你得跳过那条记录。用参数配合过滤掉DROP语句，或者用定位到DROP前的位置。操作前先复制一份binlog文件，别在原文件上改，这是基本素养。
说完数据库层面的，得提醒一句：Linux文件系统层面也有机会。如果你的数据目录在ext4或xfs上，误删的物理文件可能还没被覆盖。立刻卸载该分区（），挂载为只读，然后用或扫磁盘。这个操作对时间要求极高，文件系统在持续写入，越早动手越好。有次帮人恢复，数据文件刚删了十分钟，extundelete直接找回了全部内容，因为那个分区几乎没写入过新数据。
恢复完成之后，别急着上线。先做数据校验——对比总行数、抽查关键业务记录、检查自增ID是否断档。确认无误后，把恢复的数据导出成SQL文件，手工审查一遍，尤其是涉及金额、用户状态的字段，防止恢复出脏数据。我见过最惨的案例，恢复后没检查，结果把已注销的用户账号全激活了，客户打爆了投诉电话。
说点掏心窝子的话。数据恢复这件事，三分靠技术，七分靠日常。今天这篇指南，我就说到这儿。另外，从今天开始，把binlog开着，把备份策略做成全量加增量，把删除操作都加上WHERE条件，把DROP语句都过一遍审。你多花十分钟做的防护，可能省掉未来十个小时的折腾。
数据库这行，出过事的人才懂备份的珍贵。如果检查完了发现一切正常，那恭喜你，这篇文章对你而言只是多了一份安心。如果发现哪里不对劲，趁现在还有机会，赶紧补上。数据这东西，丢了就是丢了，找回来的每一分，都是赚到的。
