一般情况如果在大公司删库删表这种情况基本上不会遇到，毕竟给咱们开发的账号不会开这么高的权限。但是在小公司的话就不一定，没这么规范，要是咱们手抖一下，不小心删错了咋办？
比如你delete错了,把别的行给删了。然后如果你的数据库binlog配置是
binlog_format = row 和 binlog_row_image = FULL
比如你的delete语句对应的binlog event 类型是
Delete_rows event
然后将它改成
Write_rows event;
把修改的binlog拿回原库重放就行了。
如果是你update的话，那binlog里面也是记录了数据修改前和修改后的值的，你只要对调这两行数据的位置就行。
推荐使用Flashback工具，工具的原理就是我上面说的那样。
还有这种操作不建议在主库上执行，一般情况是备份一个库，或者在哪个从库上执行这些操作，确认没问题的然后再回复主库确保主库的安全。
但是有些哥们可能比较猛，他可能是drop或者truncate哪个table了或者是drop database了。这种情况下binlog记得只会是一个drop/truncate语句，所以用上面的方法是搞不定的。
咋办呢，找之前的全量备份，没得话...你懂得
找到之前的全量备份然后配合增量的日志恢复。流程就是：
找到最近一次的全量备份。比如是2019-3-25 晚上11点
通过这个备份恢复出一个临时库
在日志备份里面找到2019-3-25 晚上11点之后的日志
将这些日志除了误删除的那个语句全部应用到临时库上
第4条这个操作，如果你的数据库实例用了GTID模式，就先
set gtid_next=(你的删除语句的GTID);begin;commit;
如果没用这个模式，那只能是应用到这个删除语句之前先用-stop-position参数执行到这个语句之前，然后-start-position开始这个语句之后的执行。
我们做主从备份，为了防止误删数据导致的问题，可以搞一个延迟一小时的从库，就比如我们是一个星期备份一次的，那我们如果在第七天出了什么错，需要恢复的话，那得跑多久啊！所以弄一个特殊的备库，通过
CHANGE MASTER TO MASTER_DELAY = N
来设置这个备库和主库有N秒的延迟，这样发现主库误操作了，马上再这个备库上执行 stop slave，然后通过上面的方法跳过误删除的命令，恢复数据！
甚至还有更猛的哥们，他可能在服务器上在操作啥，比如像删除一些文件，但是搞错了，rm删了整个数据库实例....
没事别怕.....咱一般至少数据库会搞个主从的...咱删了主库，从库能顶上，对吧！项目还能跑呢！我们再从备份搞过来恢复一下咱们的主库。不怕不用跑路！
这都是发生了之后的补救措施，咱们最好就是预防一下，比如一般来说没事就不用这么高权限的账号，然后写sql的时候最好准备多个脚本，比如备份脚本，执行脚本，回滚脚本等。防范于未然！
如有错误欢迎指正！
