DROP TABLE卡顿主因是长时间持有LOCK_open全局锁并清理Buffer Pool中散落缓存页，导致Opening tables等待、page_cleaner超时及服务挂起；根本不在删文件慢。
DROP TABLE 卡顿不是因为删文件慢，而是锁住了整个表打开路径
MySQL 的 DROP TABLE 会立即进入一个被 pthread_mutex_lock(&LOCK_open) 包裹的临界区。这个锁控制所有表的打开/关闭动作——包括 SELECT、INSERT、SHOW TABLES，甚至新连接初始化时的元数据加载。一旦它被占住，所有依赖打开表的操作都会排队等待，状态变成 Opening tables 或 Waiting for table metadata lock。
常见错误现象：
- 执行
DROP TABLE big_table后，其他查询突然全部 hang 住，QPS 断崖下跌 -
SHOW PROCESSLIST中大量线程卡在Opening tables状态，持续数秒到数十秒 - 磁盘 IO 并不高，但 CPU 使用率低、
wa%却飙升（内核态 mutex 竞争导致）
Buffer Pool 扫描拖慢 DROP 是最隐蔽的瓶颈
即使文件系统删除很快（如 XFS 上 unlink() 很快），DROP TABLE 还要从每个 Buffer Pool 实例的 LRU 和 flush list 中摘除该表所有缓存页。这不是顺序扫描，而是随机跳转查找：页面散落在 old sublist 上，链表遍历本身不耗 CPU，但伴随大量 cache miss 和 mutex 争抢。
判断是否真卡在这里：
- 运行
SHOW ENGINE INNODB STATUS\G，查看SEMAPHORES部分是否有长时间等待buf_pool_mutex - 查缓存页数量：
SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME = 'db/tbl';—— 超过 1000 就危险 -
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';若 >64GB，LRU 链表极长，扫描耗时呈非线性增长
硬链接 + truncate 是唯一能卸载 rm IO 冲击的实操方案
前提是 innodb_file_per_table = ON（检查：SHOW VARIABLES LIKE 'innodb_file_per_table';）。只有这时每张表才对应独立 .ibd 文件，才能用硬链接把物理删除延迟到你可控的后续步骤。
正确操作顺序：
- 先建硬链接：
ln /var/lib/mysql/db/tbl.ibd /tmp/tbl.ibd.hdlk - 再在 MySQL 中执行：
DROP TABLE IF EXISTS tbl;（此时只删定义和 .frm，.ibd 内容仍在） - 最后对硬链接文件做
truncate -s 0 /tmp/tbl.ibd.hdlk（瞬时完成，仅改 inode 大小） - 再
rm /tmp/tbl.ibd.hdlk（这时才真正释放磁盘块）
错误做法：ln tbl.ibd tbl.hdlk && DROP TABLE && rm tbl.hdlk —— rm 仍是一次性同步 I/O，毫无缓解效果。
AHI 清理可能引发 page_cleaner 连锁超时
删除表还要清理自适应哈希索引（AHI），而 AHI 条目是基于 buffer pool page 构建的 hash 表。DROP 需逐个定位并删除对应条目，这会与 page_cleaner 线程争抢 dict_operation_lock。一旦卡住，page_cleaner loop 延迟超 4 秒，error log 出现：
page_cleaner: 1000ms intended loop took 24915ms. (flushed=182 and evicted=0, during the time.)
这不是孤立日志，而是连锁反应起点：page_cleaner 卡住 → flush list 积压 → 新写入被迫等待 → 更多线程堆积在 LOCK_open。临时缓解可关 AHI：SET GLOBAL innodb_adaptive_hash_index = OFF;，但需评估对点查性能的影响。
真正难处理的从来不是“删哪张表”，而是“这张表有多少页还活在 buffer pool 里”——它不暴露在慢查询日志中，也不报错，只在你 DROP 的瞬间，把所有积压的内存结构压力一次性释放出来。
