DELETE后.ibd文件不缩小是InnoDB正常设计，因仅逻辑标记删除行并加入空闲链表供复用，物理页未归还OS；必须通过OPTIMIZE TABLE或ALTER TABLE ENGINE=InnoDB重建表才能真正释放空间。

DELETE 不会让 .ibd 文件变小，这是 InnoDB 的设计行为，不是故障，也不是配置错误。

为什么 DELETE 后 .ibd 文件大小不变

InnoDB 删除行只是把记录头标记为 deleted，并把对应空间加入页内的空闲链表，供后续 INSERT 复用。物理文件尺寸完全不受影响。

• 即使 SELECT COUNT(*) = 0，du -sh table.ibd、Data_length、SHOW TABLE STATUS 全部不会下降
• 页（Page）没被回收，操作系统就看不到“可释放空间”
• PURGE 线程只清理 undo 日志和行级 slot，**不把页归还给文件系统**
• 如果 innodb_file_per_table = OFF，所有表共用 ibdata1，删再多也永远不缩 —— 这个参数必须为 ON 才有释放可能

OPTIMIZE TABLE 和 ALTER TABLE ... ENGINE=InnoDB 到底做了什么

它们本质都是重建表：创建新表 → 全量扫描旧表主键顺序写入 → 原子重命名 → 删除旧表。只有这个过程才能让旧页真正丢弃，OS 层面回收空间。

kashen-mysql DDLtoExcel

解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。

下载

• MySQL 8.0 默认走 ALGORITHM=INPLACE，但仍需短暂加 DDL 锁，大表可能卡住元数据锁（metadata lock）
• 执行前务必确认 innodb_file_per_table = ON，否则重建后仍写入 ibdata1，白忙一场
• Data_free 值很大 ≠ 能缩容；如果表本身刚批量插入又全删，重建后文件大小可能几乎不变
• 别在从库上直接跑 —— 它不走 binlog，主从 .ibd 文件大小会不一致

线上大表不能停，还能怎么释放空间

纯 SQL 没有“在线 shrink .ibd”的能力。InnoDB 不支持动态收缩数据文件，这是引擎层硬限制。

• pt-online-schema-change 是目前最稳妥的方案：边复制边同步，最后原子切换，业务无感知，但要求磁盘剩余空间 ≥ 表原始大小
• mysqldump + DROP + CREATE + INSERT 可行，但耗时长、IO 压力大，且中间存在数据窗口期
• TRUNCATE TABLE 能立刻释放空间，但它不是万能解法：不能带 WHERE、不支持外键引用的子表、不走 row 格式 binlog，审计场景慎用
• 重建操作本身会短暂占用双倍磁盘空间，且 purge 被阻塞时（比如有长事务未提交），即使 OPTIMIZE TABLE 跑完，实际释放量也可能远低于预期——得先看 SHOW ENGINE INNODB STATUS\G 里的历史列表长度

真正释放空间的关键不在“删”，而在“重建”；最容易被忽略的是：重建前没检查长事务，或误以为 ALTER TABLE ... ENGINE=InnoDB 比 OPTIMIZE TABLE 更轻量——它们底层完全等价。