mysql相关程序找不到_MySQL误删数据库程序员救命指南 教你跑路老板都找不到的那种...

原标题：MySQL误删数据库程序员救命指南 教你跑路老板都找不到的那种

程序员删库后怎么面对老板？我教你们

言归正题

事情缘起有次上课，大家聊起亲手造了啥大故障，排名最前的几种是：

误删文件。

误删库、表。

错误全表删除 / 更新。

升级操作失误。

没有备份

硬盘损坏

自己看看曾经命中几个。

先说几点我平时预防误操作导致文件/数据丢失不成熟的建议：

欲删除文件时，将rm命令改成mv，可在系统层面将rm命令做个alias(或参考Windows / Mac OSX做法，删除文件时先进回收站)。

删除数据库、表时，不要用drop命令，而是rename到一个专用归档库里；

删除表中数据时，不要直接用delete或truncate命令，尤其是truncate命令，目前不支持事务，无法回滚。

用delete命令删除数据时，应当先显式开启事务，这样误操作时，还有机会进行回滚。

要大批量删除数据时，可以将这些数据insert...select到一个新表，确认无误后再删除。或者反其道行之，把要保留的数据写到新表，然后将表重命名对掉。

执行重要命令之前，先准备好相关命令，再三确认无误才之行，对于新鸟而言，最好请你的boss坐你旁边镇场几次，否则极有可能会连累大家～

7.用事务保护。在更新数据和删除数据时，要特别留意比如忘记写where或者写错了where的情况。所以始终要预先确定要更新/删除的行有多少条。但DBA不可能总是清楚即将会变更多少行数据，所以需要由SQL执行的提出者先从生产库上执行select拿到大致要修改的数据量，然后与DBA确认。

以上几条，都是我自己终身奉行的原则。总之，要时刻保持对线上生产环境的敬畏之心。虽说现在大部分操作可以靠平台来完成了，但平台也不是万能的，也发生过平台本身的缺陷造成数据丢失、代码回滚、部署失误等事故嘛。

如果真的删除了怎么办？

-----做好备份，不管是物理备份还是逻辑备份！

说完预防措施之后，再说如果发生误操作时，怎么做才能以最快的速度抢救。 我们分别列举几种常见的情况：

执行DROP DATABASE / DROP TABLE命令误删库表，如果碰巧采用共享表空间模式的话，还有恢复的机会。如果没有，请直接从备份文件恢复吧。神马，你连备份文件都没有？那麻烦退出DBA届吧，一个连备份都懒得做的人，不配成为DBA的。

接上，采用共享表空间模式下，误删后立刻杀掉(kill -9)mysql相关进程(mysqld_safe、mysqld)，然后尝试从ibdataX文件中恢复数据。

误删除正在运行中的MySQL表ibd或ibdataX文件。请立即申请对该实例进行维护，当然，不是指把实例关闭，而是把业务暂停，或者把该实例从线上环境摘除，不再写入新数据，然后利用linux系统的proc文件特点，把该ibd文件从内存中拷出来，再进行恢复，因为此时mysqld实例在内存中是保持打开该文件的，切记这时不要把mysqld实例关闭了。

接上，把复制出来的ibdataX或ibd文件拷贝回datadir后，重启mysqld进入recovery模式，innodb_force_recovery 选项从 0 - 6 逐级测试，直至能备份出(整个实例或单表的)所有数据后，再重建实例(或单表)，恢复数据。

未开启事务模式下，执行delete误删数据。意识到后立即将mysqld(以及mysqld_safe)进程杀掉(kill -9)，不要任何犹豫，然后再用工具将表空间数据读取出来。因为执行delete删除后，实际数据并没被物理清除，只是先打上deleted-mark标签，后续再统一清理，因此还有时间差。

执行truncate误清整表。如果没使用共享表空间模式的话，基本别想了，走备份恢复+binlog吧。

执行不带where条件的update，或者update错数据。也别费劲了，走备份恢复+binlog吧。

如果以上都没有救怎么办？？？？

或许你会想到更好的办法进行补救，总之人在绝境的情况下也许会发生点奇迹，不是吗？

如果你什么方法都试了还是没有用怎么办？

此时你最应该做的就是老板发现之前跑路了。。。。返回搜狐，查看更多

责任编辑：