MySQL 相关的误删数据，有这样几种分类：
- 使用 delete 语句误删数据行
- 使用 drop table 或者
truncate table语句误删数据表 - 使用
drop database语句误删数据库
一、误删行
如果使用 delete 命令误删了数据行，可以用 Flashback 工具把数据恢复回来。
Flashback 的原理：修改 binlog 的内容，拿回原库重放。而能够使用这个方案的前提是，需要确保 binlog_format=row 和 binlog_row_image=FULL。
具体恢复数据时，对单个事务可以做如下处理：
- 对于 insert 语句，对应的
binlog event类型时Write_rows event，把他改为Delete_rows event即可 - 同理，对于 delete 语句，将
Delete_rows event改为Write_rows event即可 - 如果是
Update_rows的话，binlog 中记录了数据行修改前和修改后的值，对调这两行的位置即可。
如果误删数据涉及到了多个事务的话，需要将事务的顺序调过来再执行。
注意：一般情况下不要在主库上执行这些操作。
恢复数据比较安全的做法是：恢复出一个备份，或者找一个从库作为临时库，在这个临时库上执行这些操作，然后再将确认过的临时库的数据，恢复回主库。
因为可能在之前误删操作的基础上，业务代码逻辑又继续修改了其他数据。所以，如果这时候单独恢复这几行数据，而又未经过确认的话，就可能会出现对数据的二次破坏。
如何提前预防误删数据：
- 把
sql_safe_update参数设置为 on。这样的话，如果在 delete 或者 update 语句中没有写 where 条件，或者 where 条件中没有包含索引字段的话，这条语句的执行就会报错 - 人为增加流程，代码上线前，必须经过 SQL 审计。
二、误删库/表
误删库或表，一般是 drop 或 truncate 命令， binlog 中只有 drop/truncate 语句，无法恢复数据。
想要恢复数据，就需要使用 “全量备份+增量日志” 的方式，要求线上有定期的全量备份，并且实时备份 binlog。
比如有人中午12点误删了一个库，恢复数据的流程如下：
- 取最近一次全量备份，假设这个库是一天一备，上次备份是当天 0 点；
- 用备份恢复出一个临时库
- 从日志备份中，取出凌晨 0 点之后的日志
- 把这些日志，除了误删数据的语句外，全部应用到临时库
为了加速数据恢复，如果这个临时库上有多个数据库，在使用 mysqlbinlog 命令时，可以加上 --database 参数指定库。可以避免恢复数据时还要应用其他数据库的情况。
在恢复数据的时候，需要跳过 12 点那会误操作的那个语句。MySQL 现在一般是 GTID 模式，假设误操作命令的 GTID 是 gtid1，那么只需要执行 set gtid_next=gtid1; begin; commit; 先把这个 GTID 加到临时实例的 GTID 集合，之后按顺序执行 binlog 的时候，就会自动跳过误操作的语句。
建议：把数据恢复的功能做成自动化工具，并且经常拿出来测试一下。在发生误删库时，可以及时恢复数据，将损失降到最小。
预防：
- 账户分离，设置合理的权限。
- 在删除数据表之前，必须先对表做改名操作，然后观察一段时间后，确保对业务无影响以后再删除这张表。而且在改表名之前，要求给表名加固定的后缀（比如
_to_be_deleted），然后删除表的动作必须通过 SQL 审计之后执行。并且删除表的时候只能删除固定后缀的表。