先看MySQL误删数据排行榜：1.误删文件2.误删数据库和表3.误删/更新所有表4.升级操作让我们看看你犯了多少错误，hoho。就说一个我亲手造成的大事故吧。大概是一个春暖花开的季节，我的心里充满了激动，因为假期的计划已经安排好了。这几天部署了一个新项目的数据库环境，包括自动备份。就在我美美的出去玩的时候，悲剧发生了。业务要求数据回滚，发现备份文件不可用，原因是备份时指定的字符集与表字符集不一致。不好意思，原来是项目使用了新的字符集，没有仔细检查，没有修改备份脚本，导致备份失效。***，因为这件事，当季度业绩业绩被降级的时候，老板也背锅了~好了，言归正传，我来说说一些防止误操作导致文件/数据丢失的不成熟建议：1.当你要删除文件时，把rm命令改成mv，就可以在系统级给rm命令做一个别名（或者参考Windows/MacOSX的方法，删除时前进到回收站文件）。删除数据库和表时，不要使用drop命令，而是重命名到专用的归档库中；2、删除表中的数据时，不要直接使用delete或truncate命令，尤其是truncate命令，目前不支持事务，不能回滚。3、使用delete命令删除数据时，首先要显式开启事务，这样出错时才有回滚的机会。4、大量删除数据时，可以insert...select数据到新表中，确认无误后删除。或者反其道而行之，将要保留的数据写到一个新的表中，然后重命名该表来更正。5、执行重要指令前，先准备相关指令，确认无误后方可进行。新鸟，最好让你的老大坐在你旁边坐几次，不然很有可能连累大家~以上几个也是我自己奉行的原则。总之，我们要时刻保持对线上生产环境的敬畏。虽然现在大部分操作都可以由平台来完成，但平台并不完善，曾出现过因平台自身缺陷导致的数据丢失、代码回滚、部署错误等事故，这里就不点名了.做好备份，不管是物理备份还是逻辑备份！做好备份，不管是物理备份还是逻辑备份！做好备份，不管是物理备份还是逻辑备份！说三件重要的事情并不过分。说完了预防措施，我们再来说说万一误操作，如何尽快补救。我们列举几种常见的情况：1.执行DROPDATABASE/DROPTABLE命令误删除了数据库表。如果恰好使用了共享表空间模式，还是有机会恢复的。如果没有，直接从备份文件中恢复。什么鬼，你连备份文件都没有？那么请退出DBA课程。连备份都懒得做的人不配当DBA。2、接下来在共享表空间模式下，误删后立即杀掉（kill-9）mysql相关进程（mysqld_safe、mysqld），然后尝试从ibdataX文件中恢复数据。3、不小心删除了正在运行的MySQL表ibd或ibdataX文件。请立即申请维护本实例。当然，这并不是说关闭实例，而是暂停业务，或者将实例从线上环境中移除，不再写入新数据。然后，利用linux系统的proc文件特性，将ibd文件从内存中复制出来，然后恢复，因为此时mysqld实例一直保持文件在内存中打开，切记此时不要关闭mysqld实例时间。4、接下来将复制的ibdataX或ibd文件复制回datadir后，重启mysqld进入recovery模式，从0到6逐步测试innodb_force_recovery选项，直到所有数据（整个实例或单表）都可以恢复备份。然后重建实例（或单表）并恢复数据。5、未启用事务模式时，执行delete误删数据。意识到后立即杀掉mysqld（和mysqld_safe）进程（kill-9），毫不犹豫，然后使用工具读取表空间数据。因为执行完delete后，并没有物理清除实际数据，而是先标记了deleted-mark标签，后面再清理，所以还是有时间差的。5.误执行truncate清表。如果不用sharedtablespace模式，基本想都别想，直接上backupandrestore+binlog就行了。6.没有where条件就执行更新，或者更新错误的数据。不用管了，直接回去恢复+binlog就好了。
