drop table卡住新查询是因为其全程持有lock_open全局锁，导致所有新查询阻塞在“opening tables”状态；同时buffer pool扫描和ahi清理引发mutex竞争与cache miss，在大规格实例上加剧延迟。
为什么DROP TABLE会卡住所有新查询
因为 DROP TABLE 从头到尾被 pthread_mutex_lock(&LOCK_open) 包裹，这个锁控制着 MySQL 打开表的全部路径。只要它没释放，任何新连接执行 SELECT、INSERT、甚至 SHOW TABLES 都会被堵在 “Opening tables” 状态。
常见现象包括：
-
SHOW PROCESSLIST里大量线程状态为Opening tables或Waiting for table metadata lock - 新连接建立后立刻 hang 住，但老连接还能继续跑（说明不是网络或连接池问题）
- 错误日志里没报错，但监控显示 QPS 断崖下跌
Buffer Pool 扫描才是真正的性能杀手
MySQL 5.7+ 的 DROP TABLE 不再同步刷脏页，但必须遍历每个 Buffer Pool 实例的 LRU 和 flush list，把该表所有缓存页逐个摘除。这不是顺序读，而是随机跳转查找——尤其当页面散落在 old sublist 上时，链表遍历本身不耗 CPU，却引发大量 mutex 竞争和 cache miss。
容易被忽略的关键点：
-
SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME = 'db/tbl'返回 >1000 就值得警惕 -
SHOW ENGINE INNODB STATUS\G中若频繁出现buf_pool_mutex等待，基本可锁定问题 - 大规格实例（如 48c488G）Buffer Pool >64GB 时，扫描耗时呈非线性增长，几万页可能卡住十几秒
MDL 锁等待常被误判为“别人在用表”
Waiting for table metadata lock 看似是某个活跃查询占着表，其实大概率是某个安静的 Sleep 连接持着 SHARED_READ 锁没放——比如 Python 脚本用 pymysql 执行完 SELECT * FROM t LIMIT 1 就退出，没 close()，也没设 autocommit=1。
查真凶不能只看等待者：
- 先确认
performance_schema.setup_instruments中wait/lock/metadata/sql/mdl是ENABLED=YES - 再执行：
SELECT OBJECT_SCHEMA, OBJECT_NAME, LOCK_TYPE, LOCK_STATUS, PROCESSLIST_ID FROM performance_schema.metadata_locks m JOIN performance_schema.threads t ON m.OWNER_THREAD_ID = t.THREAD_ID WHERE OBJECT_SCHEMA = 'your_db' AND OBJECT_NAME = 'your_table' AND LOCK_STATUS = 'GRANTED' - 重点 Kill 的是
PROCESSLIST_ID对应的Sleep线程，不是那个显示Waiting for table metadata lock的线程
AHI 清理会拖垮 page_cleaner
删表还要清理自适应哈希索引（AHI），而 AHI 是基于 buffer pool page 构建的 hash 表。DROP TABLE 时需逐个定位并删除对应条目，这会与 page_cleaner 线程争抢 dict_operation_lock。
典型症状：
- 错误日志里反复出现：
page_cleaner: 1000ms intended loop took XXXXXms. (flushed=XX and evicted=0) -
SHOW ENGINE INNODB STATUS\G的 SEMAPHORES 段显示dict_operation_lock等待飙升 - 临时缓解：执行
SET GLOBAL innodb_adaptive_hash_index = OFF，但要评估对线上点查性能的影响
真正卡住 DROP TABLE 的，往往不是磁盘删文件慢，而是三重压力叠加：全局 LOCK_open 持有、Buffer Pool 随机扫描、AHI hash 查找争抢——其中任意一项在大 Buffer Pool 或高并发下都可能成为瓶颈。排查时别只盯着 SHOW PROCESSLIST 里的等待线程，得顺着 metadata_locks、INNODB_BUFFER_PAGE、INNODB STATUS 三处指标交叉验证。
