这个时候所有的mysql的相关进程都会停止，直到drop结束，mysql才会恢复执行。出现这个情况的原因就是因为，在drop table的时候，innodb维护了一个全局锁，drop完毕锁就释放了。

这意味着，如果在白天，访问量非常大的时候，如果你在不做任何处理措施的情况下，执行了删大表的命令，整个mysql就挂在那了，在删表期间，QPS会严重下滑，然后产品经理就来找你喝茶了。所以才有了漫画中的一幕，你可以在晚上十二点，夜深人静的时候再删。

当然，有的人不服，可能会说："你可以写一个删除表的存储过程，在晚上没啥访问量的时候运行一次就行。"

我内心一惊，细想一下，只能说："大家还是别抬杠了，还是听我说一下业内通用做法。"

一个假设

先说明一下，在这里有一个前提，mysql开启了独立表空间，MySQL5.6.7之后默认开启。

也就是在my.cnf中，有这么一条配置(这些是属于mysql优化的知识，后期给大家介绍)

查看表空间状态，用下面的命令

如果innodb_file_per_table的value值为OFF，代表采用的是共享表空间。

如果innodb_file_per_table的value值为ON ，代表采用的是独立表空间。

于是，大家要问我，独立表空间和共享表空间的区别？

共享表空间：某一个数据库的所有的表数据，索引文件全部放在一个文件中，默认这个共享表空间的文件路径在data目录下。默认的文件名为:ibdata1(此文件，可以扩展成多个)。注意，在这种方式下，运维超级不方便。你看，所有数据都在一个文件里，要对单表维护，十分不方便。另外，你在做delete操作的时候，文件内会留下很多间隙，ibdata1文件不会自动收缩。换句话说，使用共享表空间来存储数据，会遭遇drop table之后，空间无法释放的问题。

独立表空间:每一个表都以独立方式来部署，每个表都有一个.frm表描述文件，还有一个.ibd文件。

.frm文件：保存了每个表的元数据，包括表结构的定义等，该文件与数据库引擎无关。

.ibd文件：保存了每个表的数据和索引的文件。

注意，在这种方式下，每个表都有自已独立的表空间，这样运维起来方便，可以实现单表在不同数据库之间的移动。另外，在执行drop table操作的时候，是可以自动回收表空间。在执行delete操作后，可以通过执行alter table TableName engine=innodb语句来整理碎片，回收部分表空间。

ps：my.cnf中的datadir就是用来设置数据存储目录

好了，上面巴拉巴拉了一大堆，我只想说一个事情:

所以，我在一开始所提到的前提，mysql需要开启独立表空间。这个假设，百分九十的情况下是成立的。如果真的遇到了，你们公司的mysql采用的是共享表空间的情况，请你和你们家的运维谈谈心，问问为啥用共享表空间。