TRUNCATE并非总能立刻释放磁盘空间：InnoDB下仅当innodb_file_per_table=ON时才真正收缩.ibd文件；若为OFF，则空间仍占用在ibdata1中；MyISAM则直接删除文件并释放空间。
TRUNCATE对大表真的能立刻释放磁盘空间？
不能，至少不总是。在MySQL中，TRUNCATE TABLE 会重置自增ID、删除所有行，并重建表结构，但是否真正归还磁盘空间给操作系统，取决于存储引擎和文件系统配置。
对于 InnoDB 表（默认引擎），TRUNCATE 实际上是先 DROP 再 CREATE 同名表——这意味着它会释放该表对应的 .ibd 文件空间，但前提是没开启 innodb_file_per_table=OFF。如果关闭了这个选项，所有表数据都挤在共享表空间 ibdata1 里，TRUNCATE 后空间根本不会回收。
-
innodb_file_per_table=ON（推荐且默认）→TRUNCATE后.ibd文件被删，磁盘空间立即释放 -
innodb_file_per_table=OFF→ 即使TRUNCATE，ibdata1不缩容，空间仍被占用 - 使用
MyISAM引擎时，TRUNCATE会直接删除.MYD和.MYI文件，空间立刻释放
TRUNCATE vs DELETE FROM：大表清空选哪个？
对千万级以上行的大表，DELETE FROM table_name 是灾难性的：它逐行删除、写 redo/undo 日志、锁表时间长、可能触发 long transaction 报错，且不释放磁盘空间（只是标记为可复用）。
TRUNCATE 是 DDL 操作，不走事务日志，不触发触发器，执行快、开销低，但有硬性限制：
- 不能带
WHERE条件，只能全删 - 不能用于被外键引用的表（除非先禁用
FOREIGN_KEY_CHECKS） - 执行后自增计数器重置为 1（
DELETE不重置） - 某些 MySQL 版本（如 5.7+）在
READ COMMITTED隔离级别下，TRUNCATE会隐式提交当前事务，导致无法回滚
执行TRUNCATE前必须检查的3件事
跳过这些检查，轻则失败报错，重则误删关键表或卡住实例。
- 确认表引擎：
SHOW CREATE TABLE table_name;查看是否为InnoDB且innodb_file_per_table开启（可通过SELECT @@innodb_file_per_table;验证） - 检查外键依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table';，如有结果需先处理依赖或临时关掉约束 - 确认无活跃长事务或备份进程正在读取该表（
SHOW PROCESSLIST;），否则TRUNCATE可能被阻塞甚至导致复制延迟
TRUNCATE后空间没减少？下一步做什么
执行完 TRUNCATE 发现磁盘使用率没降，大概率是遇到了共享表空间陷阱，或者文件系统延迟释放。别急着重启 mysqld。
- 如果是
innodb_file_per_table=OFF，唯一安全释放ibdata1空间的方式是：全库导出（mysqldump）、停止 MySQL、删除所有数据文件（ibdata1,ib_logfile*,mysql/等）、重新初始化并导入——生产环境慎用 - 检查
.ibd文件是否真被删除：ls -lh /var/lib/mysql/dbname/table_name.ibd，若文件还在，说明TRUNCATE实际没成功（比如权限不足或被其他连接 hold 住） - Linux 下可用
lsof +L1查是否有已删除但未释放的句柄（常见于 mysqld 没完全 reload 文件描述符）
大表清空不是按下回车就结束的事，真正的难点往往藏在引擎配置和文件系统层，而不是 SQL 本身。
