MySQL数据库误删怎么恢复？站长备份踩坑经验。

去年八月的一个凌晨，两点多，手机在床头震个不停，是客户打来的。网站白屏，后台进不去。我迷迷糊糊连上服务器，先去数据库里看了一眼——订单表是空的。不是少几条，是真的干干净净，一行都没有。

脑子嗡一下。翻了下操作记录，是我自己干的。白天调数据的时候在 Navicat 里写了一行 DELETE FROM orders WHERE id = 12345，试了几次没删掉，后来把 WHERE 那截删了重新写，结果写完顺手按了 Ctrl+Enter，没注意到 WHERE 已经不在里面了。表就没了。

当时第一反应还不是慌，是「没事，有备份」。我跑去看备份目录，ls -lh 一看，最新那个 .sql 文件 0 字节。往前翻，前一天也是 0 字节。再往前，大前天才有 200 多兆。心一下就凉了。查了下原因，磁盘满了，mysqldump 写不进去，脚本里我又没加判断，失败也不报警，crontab 就每天勤勤恳恳地生成一个空文件。等于我养了三个月的备份，全是空气。

后面是靠着 binlog 救回来的。做法其实不复杂，先立刻停掉写入（我直接把整个库设成只读，虽然业务已经瘫了），然后 mysqlbinlog 按时间点把误删之前那段日志导出来重放。麻烦的是我那台机器上 binlog 只留了 3 天，而且中间有一次重启，还得手动对齐 position。折腾到早上六点多，订单回来了九成多，丢了大概十几分钟的数据，客户那边我赔了顿饭。

事后我改了几个地方，都是特别小的习惯：备份脚本里加 [ -s 文件 ] 判断文件非空，失败就发邮件；mysqldump 带上 --single-transaction；binlog 保留期从 3 天调到 14 天；还有最重要的，执行 DELETE 和 UPDATE 之前先敲 SELECT 看一眼影响行数，别直接回车。

说真的，备份这东西，不验证就等于没有。我现在每个月都会抽一个备份文件恢复到测试库跑一遍，虽然有点烦，但比凌晨两点被人打电话强。