truncate table在innodb下不会立即释放磁盘空间，仅清空数据页并重置auto_increment，.ibd文件大小不变；需配合optimize table或alter table才能收缩文件。
Truncate 表后空间不释放？MySQL 的存储引擎决定一切
直接说结论：TRUNCATE TABLE 在 InnoDB 下通常**不会立即归还磁盘空间给操作系统**，尤其当表使用独立表空间（innodb_file_per_table=ON）时，它只是清空数据页、重置 AUTO_INCREMENT，但.ibd 文件大小不变。只有在 MyISAM 下，TRUNCATE 才会真实删文件再重建。
常见错误现象：执行完 TRUNCATE TABLE logs_2023，du -sh *.ibd 看大小纹丝不动，监控里磁盘占用毫无变化。
- 确认引擎：
SHOW CREATE TABLE logs_2023，重点看ENGINE=InnoDB - 检查配置：
SELECT @@innodb_file_per_table，为 1 才走独立表空间路径 -
TRUNCATE后必须跟OPTIMIZE TABLE（或ALTER TABLE ... ENGINE=InnoDB）才能真正收缩 .ibd 文件 - 注意：
TRUNCATE是 DDL 操作，会隐式提交，无法回滚；且会重置自增计数器，这点和DELETE FROM本质不同
Optimize Table 为什么有时快有时卡死？看是不是锁表+重建
OPTIMIZE TABLE 对 InnoDB 实际等价于 ALTER TABLE ... ENGINE=InnoDB，核心动作是「创建新表 → 拷贝数据 → 删除旧表 → 重命名」。这意味着它要读全量数据、写新文件、全程持有 S（共享）锁（8.0+ 支持部分并发 DML，但仍有阻塞），高峰期容易拖慢业务。
典型卡顿场景：一张 200GB 的历史订单表执行 OPTIMIZE TABLE orders_history，持续数小时，期间 SELECT 延迟飙升，INSERT/UPDATE 阻塞排队。
- 不是所有情况都需要
OPTIMIZE：如果表没有频繁 DELETE/UPDATE 导致大量空闲页碎片，OPTIMIZE只是白费 IO - 查看碎片程度：
SELECT DATA_LENGTH, DATA_FREE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'orders_history'；若DATA_FREE占比 > 25%，才值得优化 - 生产环境务必避开流量高峰；大表建议用
pt-online-schema-change替代，避免锁表 -
OPTIMIZE会重建二级索引，如果索引字段含大文本（如TEXT），可能触发临时磁盘爆满（/tmp或innodb_tmpdir）
delete + optimize 不如直接 truncate + optimize？别被事务迷惑
有人想“安全点”，先 DELETE FROM logs_old WHERE create_time 再 <code>OPTIMIZE，结果发现更慢、更占空间——因为 DELETE 只打删除标记，不释放页，反而让 OPTIMIZE 要搬运更多“逻辑存在但物理已删”的记录。
关键区别在于：是否需要保留部分数据。如果目标是清空整张表，TRUNCATE 是唯一合理起点。
-
DELETE逐行记录 binlog，主从延迟高；TRUNCATE只记一条 DDL 日志，复制更快 -
DELETE触发外键检查、触发器；TRUNCATE完全绕过，所以更快但也更“粗暴” - 如果表有外键引用，
TRUNCATE直接报错：Cannot truncate a table referenced in a foreign key constraint，此时只能DELETE或先删约束 - 想留几条测试数据？别用
DELETE后OPTIMIZE，改用CREATE TABLE logs_new AS SELECT * FROM logs_old WHERE id IN (1,2,3)，再DROP/RENAME
清理后空间还是没下来？检查 undo log 和系统表空间
即使 TRUNCATE + OPTIMIZE 成功，磁盘空间仍不释放，大概率不是用户表问题，而是 MySQL 自身的“隐藏消耗”：活跃的长事务导致 undo log 无法回收，或者系统表空间（ibdata1）撑满。
典型表现：ls -lh /var/lib/mysql/ 发现 ibdata1 有 300GB，但所有 .ibd 加起来才 50GB；SHOW ENGINE INNODB STATUS 里 HISTORY LIST 长度上万。
- 查长事务：
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5，重点关注TRX_STATE = 'RUNNING'且TRX_STARTED很早的 - 关掉非必要应用连接，或杀掉异常事务：
KILL [trx_mysql_thread_id] - 如果
innodb_undo_tablespaces> 1 且启用了独立 undo 表空间，可考虑DROP UNDO TABLESPACE（需先SET GLOBAL innodb_undo_log_truncate=ON） - 系统表空间无法在线收缩，唯一办法是 mysqldump 全库 → 停库 → 删 ibdata1 → 重启初始化 → 导入，成本极高，慎操作
真正难的从来不是跑一条命令，而是分清“表空间”“undo 空间”“redo 空间”“临时表空间”各自在哪涨、为何不缩——搞混这四块，再勤快地 OPTIMIZE 也没用。
