1. 使用delete语句
恢复方式：使用binlog，利用Flashback工具恢复，Flashback的原理是修改binlog拿到原库里回放，这个方案的前提是binlog_format=row 并且binlog_row_image=full
单个事务的处理：1.insert 对应的 write_row event 改成delete_row event
2.delete 对应的 delete_row event 改成write_row event
3.update binlog中记录了修改前和修改后的值，对掉位置就可以了
多个事务的处理注意调整事务的顺序，说完事后处理，下面说下事前预防：1.将sql_safe_updates设置为on，这样delete和update中无where子句的语句就会报错，生产如果要执行整表删除可以用truncate或者where 1=1。2.上线，必须做sql审计，至少也要在测试环境完成验证。
2. 使用drop、truncate删除表以及drop删除库
恢复方式：全量备份+binlog恢复，这里无法使用Flashback工具，原因是drop table、truncate table 即使用的是binlog_format=row但在binlog中记录还是statement格式
恢复的技巧：因为使用mysqlbinlog无法指定表恢复，可以将全量恢复出的临时库做为主库的备库，然后指定表恢复，可以加快恢复速度。恢复方式：使用延迟复制的备库，5.6以后的功能通过change master to master_delay=N,N的单位是秒。
change master to master_delay=N
减少误操作的建议，账号分离:1.业务账号，默认只给select update insert权限，delete权限需要按表申请，DDL通过运维平台完成，如有自动建表的需求，可以指定分create table的权限。2.开发同事和dba只给只读权限，变更操作通过运维平台完成，如果需要更高权限，再单独申请。3.删除表的时候遵循修先改表名再删除的方式操作，表名统一命名前缀，并放到指定的临时库里，删除操作由平台自动统一完成。
3. 使用rm删除实例
这个就只能靠我们的HA了，如果系统层面误操作，把我们的集群主机干掉了，那就得靠我们的跨机房HA了。
4. 小结
以上是对误删除数据恢复的总结，作为dba我们也要时刻关注业务，虽然被误删除的数据一定是要找回来的，但是恢复业务不一定要恢复全部数据。
举个例子,我们误操作的是一张日志表只写不读那就不影响业务，给我们恢复的时间就比较宽裕，不恢复那是肯定不行滴！又或者是我们进行了drop table，交易要写这张表，几乎不读，那先恢复个表结构。这些要日常积累业务知识，并迅速与开发确认，确保自己做出的决策能恢复业务且不影响业务完整性。
每次误操作都是血的教训，在没有想清楚sql执行的结果之前，先不要敲下回车键哦！数据是公司的生命线，我们做为数据库管理员，要守好公司的生命线。
最后，作为dba技术原理要精通，库对应的业务也要了解哦，这样遇到问题的时候我们才能找到更全面更合理的解决方案。
Enjoy MySQL 🙂
