MySQL执行drop表卡住，如何排查BufferPool LRU链表扫描压力问题？

本文共计732个文字，预计阅读时间需要3分钟。

MySQL 5.6 的 InnoDB 引擎在执行 `DROP TABLE` 命令时，不会立即刷新脏页，而是首先从每个 Buffer Pool 实例的 LRU 和 flush list 中移除对应的页。这个过程需要遍历整个 LRU 链表（即 old sublist），如果 Buffer Pool 设置过大（例如超过 16GB）或表已被大量访问导致页面散落在各个位置，遍历时间可能会变长——这会导致 `DROP` 操作卡住，表现为卡在 `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 成为压垮缓冲池的最后一根稻草。