上周半夜三点，朋友老张的电话把我吵醒，声音带着哭腔：“完了，我手贱，把整个数据库删了。”我一边揉眼睛一边问他有没有备份，他支支吾吾说有备份，但是三个月前的。这种事在 DBA 圈子里太常见了，谁没在半夜被噩梦惊醒过？MySQL 恢复被删除的数据库听起来吓人，其实要看情况。如果是正常的 DROP DATABASE 操作且没有备份，只能靠 binlog 或数据文件来救命；如果运气好，数据库文件还在磁盘上未被覆盖，那还有戏。不过先泼盆冷水：千万别急着重启 MySQL，也别往数据目录写东西，不然神仙都救不了。
先说最简单的情况：你有全量备份，还有 binlog。恢复流程并不复杂，先在干净的环境把备份还原出来，然后用 mysqlbinlog 工具把从备份时间点到删除操作之前的所有 binlog 解析成 SQL，导回去。关键是要弄清楚删除操作的具体时间，因为 binlog 里会记录每个事务的时间戳。比如备份是凌晨 2 点做的，发现数据库在凌晨 3 点 15 分被删，那就把 2 点到 3 点 14 分 59 秒的 binlog 全部恢复。但有个坑：binlog 默认会自动清理，如果过期时间设置太短（比如只有 7 天），超过 7 天的 binlog 就没有了，这时候再哭也没用。
如果连备份都没有，只能靠数据文件硬拼。InnoDB 引擎有个特性，只要没有执行 TRUNCATE TABLE 或 DROP TABLE，数据文件里的记录其实仍在。但 DROP DATABASE 会直接删除整个数据库目录，这时要看操作系统是否开启了回收站或文件系统快照。Linux 上可以用 extundelete 这类工具扫描磁盘，找回被删除的 .ibd 文件。我见过最夸张的一次，一个运维小哥把数据库目录 rm -rf 了，结果用 extundelete 硬是捞回了 80% 的数据，虽然有些表结构丢了，但核心业务数据保住了。不过这种方法极度依赖运气，磁盘空间被新数据覆盖得越多，找回的概率就越低。如果删除后马上跑了大查询，或者系统自动做了日志轮转，基本就凉了。
还有个偏方：用 mysqlbinlog 直接解析 binlog，抓出删除操作的 SQL，然后反向构造恢复语句。比如 binlog 里记录的是 “DROP DATABASE test”，可以把它改写成 “CREATE DATABASE test” 再加上对应的表结构。但这种做法只适用于你清楚数据库里有哪些表且表结构没有变过。实际操作中，很多人连自己库里有多少张表都说不清，更别提字段类型了。所以这个方案更适合对数据库结构了如指掌的老手，新手千万别尝试，越折腾越乱。
说到这里，得提一嘴 MySQL 的“延时复制”功能。很多大厂的生产环境会配置一个延时从库，让主库的数据变更延迟 1 小时才同步到从库。这样万一误操作，你还有 1 小时的时间从从库里把数据捞回来。我有个朋友在电商公司，他们就是这么做的，有一次运营同学手滑删了用户订单表，直接从延时从库导出来就完事，前后不到 10 分钟。如果你的业务重要，建议至少配一个延时从库，成本不高，但关键时刻能救命。
说实话，与其研究怎么恢复，不如把精力花在预防上。我见过太多公司，数据库权限管理一塌糊涂，开发人员手里握着 DROP 权限，测试环境和生产环境混用。有一次实习生在生产库上跑测试脚本，直接 DROP DATABASE，连确认都没有弹。后来公司痛定思痛，给生产库加了严格的权限控制，每个操作都要走审批流程，还强制开启 binlog 并定期备份。现在很多云厂商的 RDS 已经把这些防护措施做得很完善，比如自动备份、一键恢复到任意时间点、回收站机制等。如果你还在用自建 MySQL，建议至少做到三点：① 开启 binlog 并保留 7 天以上；② 每天全量备份并异地存储；③ 数据库操作权限最小化，尤其是 DROP 和 TRUNCATE 权限。
说个真实案例。去年有个做跨境电商的朋友，数据库被删后尝试用第三方工具恢复，结果工具在扫描磁盘时把数据目录写坏了，本来还能找回的 .ibd 文件彻底废了。后来他们花了两万块请专业数据恢复公司，对方用磁盘镜像技术，从底层扇区慢慢读，折腾了三天，恢复了 90% 的数据。但代价是业务停了整整一周，损失超过百万。所以，如果真的遇到这种情况，第一步一定是先做磁盘镜像，保护原始数据，然后找专业人士处理。千万别自己瞎折腾，尤其别用来路不明的“一键恢复”软件，十有八九越帮越忙。说到底，数据库安全靠的不是技术，而是习惯和制度。你永远不知道下一个手滑的人会不会是自己，但你知道，备份永远不嫌多。
