mysql相对oracle来说，自带的恢复手段较少。下面罗列下不同场景下mysql的恢复的手段：
1删除表
在有备份的情况下，一般都是通过备份+binlog来进行恢复。在没有备份的情况下可以使用undrop工具进行恢复，但是这个工具在使用上有些问题，在drop表后进行表结构的恢复中没有指定端口的参数，只能是默认的3306端口，需要修改源码添加指定端口的参数。在恢复的时候需要扫描磁盘，机器的cpu数越多，并发越高，速度越快,这个工具针对drop table的恢复有些蛋疼，在恢复表结构的时候，需要扫描整个分区，如果分区很大，那么对于磁盘的消耗是很大的，也许是我使用姿势不对？？这个工具另外的问题是扫描的块不一定总能找的到，不知道为什么，即使是扫了真个的磁盘也找不到合适的page，前提已经将数据刷到了磁盘上。没有看源码，不知道是怎么弄的，写了个shell自动还原，一开始能找到page，但是没有数据，后来就开始找不到page了，有些崩溃，准备扒源码看看。
2删除数据，误更新
这种方式也可以使用备份+binlog的方式恢复，但是如果备份很大，在恢复的时候也需要很长的时间，线上有的业务不一定能接受，可以考虑使用下mysqlbinlog_flashback工具进行闪回
3剩下的基于时间点的恢复只能是备份+binlog来进行了,这种用binlog来恢复的方式也有不同的使用方法，第一个是使用之前的备份+备份的binlog在别的机器上进行恢复，第二种方式是使用之前的备份制作从库，配置指向master，在恢复到指定的位置后停止，这个需要master上保存有需要binlog。
4进行基于表的指定时间点的恢复，这种的恢复，可以在使用备份配置成从库后，然后指定复制过滤来复制指定的表，加快恢复的速度。
上面的这3中方式能覆盖大多数的恢复场景。