DROP TABLE 会立即调用 unlink() 删除物理文件，触发同步I/O和buffer pool清理锁；开启innodb_file_per_table=ON后可用硬链接+truncate分步卸载IO压力。
DROP TABLE 会直接触发物理文件删除
MySQL 的 DROP TABLE 不是“逻辑标记删除”，而是立即调用操作系统 unlink() 系统调用，从文件系统层面抹除 .ibd 文件。当表数据量达百 GB 级别时，这个操作本身不耗 CPU，但会引发大量同步 I/O：文件系统需更新 inode、block bitmap、journal 日志等元数据，同时 SSD 或 HDD 要实际擦除或重映射物理块 —— 这一过程无法缓冲或异步化，IO 峰值直接打满磁盘带宽。
innodb_file_per_table=ON 是硬链接方案的前提
只有开启该参数，每张表才对应独立的 .ibd 文件；否则数据混存在共享表空间 ibdata1 中，DROP TABLE 只释放内部页，不删文件，也就没法用硬链接规避 IO。检查方式：SHOW VARIABLES LIKE 'innodb_file_per_table'; 返回 ON 才可继续。
- 若为
OFF，必须先ALTER TABLE ... ENGINE=InnoDB;搬迁到独立表空间（注意：该操作本身也重写全表，需评估窗口） - 搬迁后首次
DROP仍会触发 IO，但后续大表清理就可复用硬链接流程
硬链接不能跳过 DROP，但能卸载 rm 的 IO 冲击
DROP TABLE 执行后，MySQL 仅删掉表定义和 .frm 文件，并把 .ibd 文件的引用计数减 1；只要还有硬链接存在，文件内容就保留在磁盘上。真正的物理删除由后续的 rm 触发 —— 此时你完全可控：用 truncate -s 0 分块清空、或用 dd if=/dev/zero 慢速覆写、甚至挂载新盘后 mv 走再批量 rm。
- 错误做法：
ln data.ibd data.ibd.hdlk && DROP TABLE t; && rm data.ibd.hdlk——rm仍是一次性 IO - 正确做法：DROP 后对
data.ibd.hdlk执行truncate -s 0 data.ibd.hdlk，再rm；或写个循环脚本每次truncate -s -1G直至归零 - 注意：
truncate -s 0在 ext4/xfs 上几乎瞬时完成，本质是修改 inode 大小字段，不碰数据块
buffer pool 清理锁也会卡住查询
即使磁盘 IO 没爆，DROP TABLE 还要扫描 buffer pool 清理该表缓存页。MySQL 5.5.23+ 引入 lazy drop，每次最多清理 1024 页就释放 mutex，但若 buffer pool 设置过大（比如 32GB），或该表曾被高频访问导致大量脏页滞留，仍可能持有 buffer_pool_mutex 数秒 —— 这期间所有新查询都会排队等待，表现为 QPS 断崖下跌、连接堆积。
- 执行前确认无活跃事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TRX_MYSQL_THREAD_ID IN (SELECT ID FROM information_schema.PROCESSLIST WHERE INFO LIKE '%your_table%'); - 避免在业务高峰执行；如必须操作，优先选只读从库做演练，观察 buffer pool 清理耗时
- 监控指标重点看
Innodb_buffer_pool_wait_free和Threads_running突增
真正麻烦的从来不是“怎么删”，而是删完那一瞬间没人盯着 iostat -x 1 和 SHOW PROCESSLIST —— 磁盘 IO 和 buffer pool 锁这两股压力，往往一个藏在后台，一个卡在前台，稍不留神就变成线上事故。
