今天下午差点把自己干废。
事情是这样的，上个月接了个餐饮连锁的小程序单子，八千块，主要做会员储值和积分商城。甲方之前找人做过一版，开发跑路了，代码倒是留下来了，但没文档没注释，数据库结构靠猜。
我本地搭环境，把他们的备份库导进来，想看看会员表长什么样。你猜怎么着，那个开发者没用 migrations，全是裸 SQL，表名还带前缀，什么 fx_user_2023、fx_user_temp_backup，乱得跟菜市场一样。
我寻思着先看一眼最新的表是哪张，随手敲了个命令想查一下行数。结果你猜怎么着，我手一抖，把 SELECT 打成了 DROP。
对，就是这么蠢。
等我反应过来，终端已经显示 Query OK, 0 rows affected——空表，删得干干净净。也没报错，也没警告，就这么没了。
我盯着那行字看了大概五秒钟，脑子是空的。这表里存的是他们最近三个月的会员储值记录，虽然我导的是本地备份，但问题是，这个备份是8月中的，也就是八月中旬之后的数据全没有。甲方那边生产库还在，但万一他们让我修bug修到要动数据，我拿这个残缺备份顶上，那就真完蛋了。
冷汗当场就下来了。
说白了，我第一反应是看看有没有趁手能救的，但理智告诉我这表已经被 DROP 了，没有回收站，没有 binlog（开发的时候图省事没开），唯一的希望就是那个备份文件本身。
我赶紧去翻当初甲方怎么给的备份。他们说是从服务器上导出来的，一个 .sql 文件，发我网盘了。我下载下来，用文本编辑器打开，扫了一眼——嗯，开头是 SET 语句，然后一堆 CREATE TABLE，再往下…… INSERT INTO。我以为没事，结果搜了下那个表名，没有INSERT。
这就是最操蛋的部分：那个跑路的开发导出SQL的时候，多半是用了 --no-data 还是什么的，或者当时那个表本来就是空的——反正我手上的备份里，这个表就是没有数据的空壳子。
我坐在那儿，抽了半根烟，开始算账。甲方那边知道我把备份搞坏了，我会怎么样？工期延误，赔钱，而且这三年的口碑——虽然也没多好——就砸了。这单八千，可能还得倒贴。我越想越慌，在屋里转了两圈。
后来我强迫自己冷静下来，又去翻那个网盘文件夹，看看有没有别的历史备份。翻到最底下，还真有个文件名带日期，6月头的，比上一个更老，但好歹有数据。我立马导进来，一看，会员数一千多条，虽然跟最新的差了得有小三千，但至少有表结构，能跑。
然后我就开始手动补。跑去甲方那边软磨硬泡，让他们找运维把服务器上最近的binlog开一下，或者做一次新的全备发给我。甲方运维一听就烦了，说这服务器又不是专门给你准备的，开发跑路了都没人管，要搞可以，下周再说。
我心里骂娘，嘴上还得说好话，最后说通了，他答应今晚给我拉一份最新的全备。
这账你算算：我本来今天下午能把积分商城那块的接口联调完，结果浪费了一下午，净干这事了。本来这单八天工期我报的是五天，现在好了，少说搭进去一个晚上，而且万一甲方那边的新备份也出问题，我这条小命就交代了。
其实我该庆幸删的是本地库。要是哪天我连了生产库，一个 DROP 下去……我都不敢想。
朋友之前跟我说，你操作数据库能不能先看一眼当前是哪个库哪个表，我说知道了知道了，然后今天就这样了。跑题了说回来——明天开始，我打算每次敲删除之前，先复制一遍表名贴在文本框里，然后念一遍，敲个回车，再念一遍，再敲个回车。怂是怂了点，命要紧。