drop table大表 一直卡在checking permissions

问题

今天上班的时候听到一个负责清理数据的同事（小姐姐）说drop一个table好慢花了9分钟多，作为一个DBA的我立刻觉得不太对劲儿，因为按理来说drop table应该是很快的，可是为什么会花费9分钟，起初我以为可能是DML语句导致drop table DDL等待mdl锁导致，然后和小姐姐沟通之后发现这个库目前是没有开放读写的，还没在使用，只是新搭的从库删除bak表，然后我就问她能否复现，于是又开了一个窗口，继续复现，结果还是drop table 特别慢，一直没有结果，然后我通过当时drop table的时候show processlist查看结果如下：

排查过程

看到这个checking permissions已经持续了113秒还没有结束，我觉得确实需要分析一下，于是我进一步了解到小姐姐在这个库上做过很多的导数据操作，所以最后初步判断是因为buffe_pool里面存在了太多的页，需要删除之后再进行真正的ibd文件删除，想到这之后去网上google了一下，发现和我想的差不多，在删除一个有独立表空间的大表时，需要对buffer pool中所有和这个表空间有关的数据页做清理工作，包括从AHI，flush list和LRU list上移除，而在这个清理过程中，会一直持有buffer pool的mutex。如果buffer pool配置特别大，比如500 GB大小，像小姐姐操作的这个db，buffer_pool260G，因此持有这个mutex的事件会较长，导致其他连接被阻塞住，从而导致系统性能的下降。

解决方案

我这边看到网上的一些解决方案，都是什么在业务低峰期等操作，
这边由于小姐姐是在一个还没有上线的库上删除数据，因此我让她直接重启mysqld
service，这样db重新启动的时候buffer_pool是刚初始化的，应该会drop table 很快，果不其然，小姐姐按我说的重启之后，drop table 速度非常快，零点几秒就drop掉一个大表，因为小姐姐要删除很多大表，所以在我帮助之后，删除数据效率飞速提升。

总结一下解决方案：
1.业务低峰期操作
2.如果服务可以重启，影响不是很大，直接重启服务快速drop table。