truncate快因跳过行级删除、直接释放数据页并重建表文件，但若缓冲池存大量脏页或热页则需逐页驱逐而卡住；还可通过缩小buffer pool或rename+drop绕过。
TRUNCATE 为什么快，但有时还是卡住
TRUNCATE TABLE 快，是因为它不走 InnoDB 行级删除逻辑，而是直接释放数据页、重置 AUTO_INCREMENT、删掉表的 .ibd 文件（或标记为可复用），再新建一个空文件。但「快」的前提是：InnoDB 缓冲池（buffer pool）里没有大量属于该表的脏页或热页。如果表刚被大量写入，缓冲池中存着成千上万页的缓存，TRUNCATE 就得先逐个扫描并驱逐这些页——这个过程会阻塞，看起来就像卡在 Query OK 前不动。
清空前主动清理 buffer pool 关联页
不是调大 buffer pool，而是临时减小它，让 InnoDB 扫描范围变小。实操分三步：
- 记录当前
innodb_buffer_pool_size值：SHOW VARIABLES LIKE 'innodb_buffer_pool_size'; - 动态缩小（需有 SUPER 权限）：
SET GLOBAL innodb_buffer_pool_size = 128 * 1024 * 1024;（例如缩到 128MB） - 立刻执行
TRUNCATE TABLE your_table;，完成后恢复原值：SET GLOBAL innodb_buffer_pool_size = 2147483648;
注意：该操作会触发 buffer pool 重建，期间新连接可能短暂变慢；别在业务高峰做。MySQL 8.0.22+ 支持在线调整 buffer pool 大小，但仍是「重建分片」而非「平滑缩容」，本质没变。
用 rename + drop 替代 TRUNCATE 的真实场景
当表太大（比如 >50GB）、buffer pool 又无法临时调整（如云数据库 RDS 不开放 SET GLOBAL），或者你怀疑 AHI（Adaptive Hash Index）残留导致卡顿，可以用文件系统层绕过：
- 新建空表结构：
CREATE TABLE your_table_new LIKE your_table; - 原子重命名交换：
RENAME TABLE your_table TO your_table_bak, your_table_new TO your_table; - 异步删旧表：
DROP TABLE your_table_bak;（这步才是真删文件，可后台慢慢跑）
这个方案把「清空」变成「换壳」，RENAME 是毫秒级的文件系统硬链接操作（Linux ext4/xfs 下），完全避开 buffer pool 扫描。但要求你有 DROP 和 CREATE 权限，且不能有活跃事务锁住原表。
别忽略 innodb_file_per_table 和文件系统影响
确保 innodb_file_per_table = ON（MySQL 5.6.6+ 默认开启），否则 TRUNCATE 不会删 .ibd 文件，只是标记空间可复用，磁盘不会释放——你看到的「快」是假象。另外，如果表文件在 XFS 文件系统上，可配合 xfs_fsr 整理碎片；在 ext4 上，TRUNCATE 后内核回收空间更快。但别对单次操作做这些优化，它们只在反复大批量 truncate 场景下才有意义。
真正容易被忽略的是：buffer pool 扫描成本和文件系统回收延迟之间没有中间态。你以为 TRUNCATE 返回了就完事了，其实 OS 层的文件删除可能还在排队——尤其在高 IOWAIT 的机器上，df 看不到空间释放，不是 MySQL 没删，是内核还没刷完。
