数据库里误删了记录，还能还原回来吗：一次从 binlog 捞数据的实录

周五下午，一个客户的工厂群里炸了。管仓库的小伙子做数据清理，手一抖，把物料明细表里的记录删了一大片，没带条件，整表清掉了一多半。这套系统是工厂的账套底座，物料数据没了，当天的收发货全得停下。他第一反应是重新录一遍，我们让他先住手。

一、出事之后，第一件是别再动那台机器

误删数据之后，最怕的就是"想着补救、结果把现场搞得更乱"。有人会马上再操作一遍，有人会重启数据库，还有人直接拿备份覆盖上去。这几个动作都可能让本来能救的数据变得救不回来。稳妥的做法是先停业务写入，把现场冻住，再去看还有哪些手段可用。

那次我们让客户先停掉了系统入口，任何人不再往数据库写东西，然后连上去看这台服务器平时到底有没有开日志。

二、为什么日志能把删掉的数据找回来

MySQL 这类数据库，如果打开了 binlog，所有写操作——插入、更新、删除——都会按顺序记进日志文件，谁在什么时候改了什么，一条不落。这份日志本来的用途是做数据同步和恢复，可误删的时候，它就成了唯一能还原现场的记录。

关键是要找对位置。日志里每条操作都能定位到具体时间点，只要知道误删大概发生在什么时刻，就能把日志截到那一刻之前重放，把正确的数据补回来；删除那一段跳过不执行，被删的记录就回来了。原理不复杂，难的是现场别被破坏、时间点别记错。

三、一次误删的实际还原过程

那次我们的顺序是这样的：先确认误删的时间点，从客户的操作记录和数据库日志的时间戳对上；再把全量备份恢复到一台隔离的机器上，回到误删前最近的一个备份点；然后从备份点开始，把 binlog 一条条重放到误删前一刻；最后把这台机器上的正确数据，导回生产库。

整个过程都在隔离环境里做，不碰生产数据，万一重放错了也能推倒重来。折腾了大半天，删掉的物料记录基本都捞了回来，只有误删之后这半天里新产生的几条变动需要人工补录。比起整表重录，代价小得多。

四、比"能恢复"更重要的，是"用不着恢复"

事后复盘，问题出在权限上：一个日常操作岗，不该有整表删除的权限。我们把客户的账号权限重新理了一遍，危险操作收紧，关键表加上操作留痕。摩杰斯做工厂 MES、ERP 十四年，这类"差点出大事"的场景见过不少，所以给系统配的默认策略里，自动备份加 binlog 留存一直是标配，2012 年在昆山成立至今，苏州、江苏一带的客户数据都是这么保的。

备份不是摆设，要能还原、做过演练才算数。昆山、苏州一带的工厂，数据出过问题、不确定还能不能救的，可以先找摩杰斯看一眼，别急着覆盖。

总结：

数据误删，第一反应应该是停手，不是补救。现场冻住之后，如果平时开了 binlog、又有全量备份，大概率能把记录捞回来，做法就是"恢复到备份点，再把日志重放到误删前一刻"。但最好的状态是压根用不着恢复——权限收紧、危险操作留痕、备份加日志留存，这几件事做在前面，手一抖的代价才不会那么大。

相关阅读：更多同类问题可以看《工厂 IT 服务总览》；延伸阅读《默认带异地备份与还原演练》、《ERP 数据库崩溃的完整复盘》。