innodb为什么删除和修改更快
drop删除的表可以恢复吗？
drop删除的表可以恢复吗？
情况1、如果你有该库的整体备份或对这个表的单独备份，那么也许可以恢复。可以将最新的备份恢复到一个备用的服务器上，导出那表的内容，完成恢复 情况2、如果没有任何备份，那就基本没戏了。一般删除表的操作是drop table，日志中不会记录删除具体行数的记录。表所对应目录下的文件已经被删除（innodb独立表空间，单表归为一文件）。
同样的情况适用于myisam数据库引擎，对应的myd/myi/frm文件均被删除。
这不像windows还有垃圾箱，是不可逆的操作
undo日志什么时候清除？
还有一点需要注意，事务共享表空间中写入undo日志的过程同样需要写入redo日志，事务一旦提交，也就意味着事务的持久性生效，那么undo日志则不被需要，但是innodb并不会把这个undo日志直接删除，而是放在一个undo日志的链表中，到底什么时候删除取决于mysql的purge线程，这样做是为了避免其他的事务需要通过undo日志来得到这条记录之前的版本。
truncate.droptable速度很慢，为什么？
在逻辑上truncate table和delete语句都可以删除表里面所有数据，但是在一些情况下有些不同：对于InnoDB表1,如果没有外键关联，innodb执行truncate是先drop table(原始表),再创建一个跟原始表一样空表,速度要远远快于delete逐条删除行记录。
2,如果使用innodb_file_per_table参数，truncate table 能重新利用释放的硬盘空间,在InnoDB Plugin中，truncate table为自动回收，如果不是用InnoDB Plugin,那么需要使用optimize table来优化表，释放空间。
3,表有外键关联，truncate table删除表数据为逐行删除，如果外键指定级联删除(delete cascade)，关联的子表也会会被删除所有表数据。
如果外键未指定级联(cascde),truncate table逐行删除数据，如果是父行关联子表行数据，将会报错。4,auto_increment计数器在truncate table后会重置为0.与是否有外键关联没有关系。