DROP TABLE 确实立刻释放磁盘空间，但仅当 innodb_file_per_table=ON 时 InnoDB 才能真正删除 .ibd 文件并归还空间；MyISAM 总是直接删除 .MYD/.MYI 文件，释放更确定；若文件被进程占用、文件系统延迟或使用共享表空间（ibdata1），则 df 可能暂不显示变化。
DROP TABLE 确实会释放磁盘空间，但是否“立刻可见”取决于存储引擎和文件系统配置。InnoDB 和 MyISAM 的行为一致：只要满足条件，DROP TABLE 之后对应的数据文件（如 .ibd 或 .MYD）会被操作系统级删除，磁盘空间立即归还。但现实中常因配置或残留导致“看起来没释放”，下面分情况说明。
确认是否启用了 innodb_file_per_table
这是最关键的前置条件。只有开启该选项，每个表才独占一个 .ibd 文件；否则所有 InnoDB 表共用 ibdata1，DROP TABLE 只回收内部页，不删文件、不释放磁盘。
- 检查命令：
SHOW VARIABLES LIKE 'innodb_file_per_table';—— 返回ON才有效 - 若为
OFF，DROP TABLE后空间仍留在ibdata1中，无法通过删表释放，只能重建整个实例 - 该变量不可动态修改，需在
my.cnf中设置并重启 MySQL
执行 DROP TABLE 后空间未减少的常见原因
不是命令失效，而是你看到的是“文件系统层”或“监控工具”的延迟/错觉：
-
DROP TABLE成功后，对应.ibd文件被 unlink，但若仍有进程（如 mysqld 自身、备份工具、lsof 持有句柄）打开该文件，空间不会真正释放 —— 查看lsof | grep deleted可确认 - 某些云盘或 LVM 层不主动 TRIM，
df显示不变，但实际已可复用；可用du -sh /var/lib/mysql/dbname/对比验证 - 误把
OPTIMIZE TABLE当成必需步骤 —— 它只对 *已存在* 的表生效，DROP后无表可优化
MyISAM 表的 DROP TABLE 行为更直接
MyISAM 总是按表拆分文件（.MYD + .MYI），DROP TABLE 会同步删除这两个文件，无需额外配置。
- 只要 MySQL 进程有对应目录写权限，
df通常能立刻反映空间释放 - 注意：若使用了
--skip-external-locking或并发访问，极少数情况下文件删除可能延迟几秒 - 不依赖任何变量，比 InnoDB 更“确定性释放”
真正卡住释放的往往是数据库外因素
即使 DROP TABLE 正确执行，物理空间也可能被挡在最后一步：
- Linux 上启用
ext4的delalloc模式时，文件删除后元数据更新可能延迟 —— 强制刷盘：sync && echo 3 > /proc/sys/vm/drop_caches（仅调试用） - 容器环境（Docker/Pod）中，MySQL 数据目录挂载到 host 卷，
df要在 host 上查，而非容器内 - 使用 ZFS/Btrfs 等 Copy-on-Write 文件系统，需运行
zfs sync或btrfs filesystem sync
最常被忽略的点：你以为删了表，其实删的是临时表或视图 —— SHOW CREATE TABLE table_name 确认引擎类型；SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'; 验证真实存储引擎。InnoDB 表没释放空间？先盯死 innodb_file_per_table。
