DELETE后磁盘空间不释放是InnoDB正常设计，因仅逻辑标记删除行而不物理回收，必须通过OPTIMIZE TABLE、ALTER TABLE ENGINE=InnoDB或TRUNCATE重建表才能真正释放.ibd文件空间。
DELETE 后磁盘空间不释放，和事务是否提交无关；这是 InnoDB 的设计行为，不是 bug，也不是配置错误。
为什么 COMMIT 了空间还是不缩？
因为 DELETE 本质是逻辑删除：InnoDB 只把行头的 delete_mask 位设为 1，并更新页内的空闲链表，物理页仍保留在 .ibd 文件中。COMMIT 只是让这些“已删”状态对其他事务不可见，但不会触发页回收或文件截断。
真正负责清理旧版本数据的是后台 purge 线程，但它只做两件事：删 undo 日志、回收被标记删除的行级 slot——它从不把整页还给操作系统。所以即使你执行了 COMMIT，du -sh table.ibd 和 SHOW TABLE STATUS 中的 Data_length 依然纹丝不动。
什么情况下 purge 会被卡住？
长事务会阻塞 purge 进程，导致已删数据长期滞留，Data_free 持续偏高，碎片越积越多。但这和“空间不释放”不是同一问题——即使没有长事务，空间照样不释放。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 查活跃长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 600 - 看 purge 进度：
SHOW ENGINE INNODB STATUS\G，搜索Purge done for trx's n:o，对比当前最大事务号 -
Data_free高 ≠ 必须优化；它只是“当前可复用的空页数”，是为 INSERT 复用预留的缓冲，业务写入稳定时本就不该动
真正能缩 .ibd 文件的操作有哪些？
只有重建表才能让操作系统回收空间。以下命令都等价于“新建空表 + 拷贝有效行 + 替换文件”：
-
OPTIMIZE TABLE t：MySQL 5.7+ 对 InnoDB 表等价于ALTER TABLE t FORCE，自动加ANALYZE，但全程需两次 MDL 锁（开始前 + 替换后） -
ALTER TABLE t ENGINE=InnoDB：语义更直白，适合脚本批量操作；RDS 等托管服务可能封装为在线 DDL，但需确认是否真走了ALGORITHM=INPLACE -
TRUNCATE TABLE t：直接删.ibd再建新文件，立刻缩容，但不支持WHERE，且外键子表上会报ERROR 1701
注意：innodb_file_per_table 必须为 ON，否则所有表共用 ibdata1，删再多也缩不了系统表空间。
执行前最容易忽略的三件事
盲目跑 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 容易翻车：
- 磁盘剩余空间必须 ≥
Data_length的 1.5 倍——临时表、undo、redo 都要地方落脚，否则中途写满会卡死 - 确认没有慢查询或大事务正在执行——它们会卡住 MDL 锁，让整个重建流程挂住不动
- 检查
Data_free / Data_length是否真的远超 10%——若才几百 KB，纯属白忙；碎片是性能缓冲，不是病灶
真正关键的判断点不在“删没删完”，而在于“是否真需要 OS 层面的空间回收”以及“能否承受重建过程中的 I/O 和锁开销”。对活跃大表，一次盲目的 OPTIMIZE TABLE 可能比不优化更伤。
