DROP TABLE 卡在 Buffer Pool 扫描是因为 InnoDB 需遍历 LRU/flush list 摘除表页面，当 buffer_pool_size 过大或表缓存页过多时耗时飙升，表现为 metadata lock 等待、CPU 低但 I/O 高。
为什么 DROP TABLE 会卡在 Buffer Pool 扫描上
MySQL 5.6+ 的 InnoDB 在执行 DROP TABLE 时，并不会立刻刷脏页，而是先从每个 Buffer Pool 实例的 LRU 和 flush list 中“摘除”该表对应的所有 page。这个过程需要遍历整个 LRU 链表（尤其是 old sublist），如果 Buffer Pool 设置过大（比如 >16GB）、或表曾被大量访问导致页面散落在各处，遍历耗时就会飙升——表现为 DROP 卡住、SHOW PROCESSLIST 里状态长期停在 Waiting for table metadata lock 或 dropping table，且 CPU 不高但 I/O 等待明显。
确认是否真被 Buffer Pool 扫描拖慢
直接查关键指标比猜更可靠：
- 运行
SHOW ENGINE INNODB STATUS\G，翻到BACKGROUND THREAD和SEMAPHORES部分，看是否有线程长时间等待buf_pool_mutex或buf_pool->mutex - 检查当前 Buffer Pool 大小：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';—— 若超过物理内存的 70% 且表数据量不大，大概率是它在拖后腿 - 用
SELECT COUNT(*) FROM information_schema.INNODB_BUFFER_PAGE WHERE TABLE_NAME = 'db_name/table_name';查该表实际缓存了多少页；若返回几千甚至上万行，说明扫描压力真实存在
临时绕过 Buffer Pool 扫描阻塞的实操方法
不重启、不删数据目录，快速释放卡死的 DROP：
- 先停掉所有写入：执行
SET GLOBAL innodb_fast_shutdown = 0;（确保下次启动能彻底清理） - 关闭 AHI（自适应哈希索引）：它会额外增加遍历时的 hash 表查找开销，执行
SET GLOBAL innodb_adaptive_hash_index = OFF; - 强制刷新并清空 Buffer Pool（仅限低峰期）：
SET GLOBAL innodb_buffer_pool_dump_now = ON;→ 等几秒 →SET GLOBAL innodb_buffer_pool_load_now = OFF;→ 再等片刻，让旧页自然老化出 LRU - 此时再试
DROP TABLE IF EXISTS your_table;，通常能明显提速
真正治本：删大表前必须做的三件事
Buffer Pool 扫描只是表象，根源常在设计和操作习惯：
- 删前必查外键：
SELECT CONSTRAINT_NAME, REFERENCED_TABLE_NAME FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't';—— 存在外键却没处理，DROP 会卡在元数据锁等待 - 避免高峰期删 >1GB 的表；若必须删，优先用
TRUNCATE TABLE（更快、不走逐页扫描逻辑），或分批DELETE ... LIMIT 10000+OPTIMIZE TABLE - 长期方案：把
innodb_buffer_pool_size调整为物理内存的 50%~60%，并监控Innodb_buffer_pool_read_requests / Innodb_buffer_pool_reads比值，低于 99% 就说明 Buffer Pool 利用率已过载
Buffer Pool 扫描本身不可跳过，但它的代价可以被显著压缩——关键是别让 DROP 成为压垮缓冲池的最后一根稻草。
