delete后磁盘空间不释放是innodb正常设计行为，仅逻辑标记删除行而不物理回收，必须通过optimize table或alter table engine=innodb重建表才能真正释放.ibd文件空间。
DELETE 后空间不释放是正常行为，不是 bug
SQL 的 DELETE 语句只是把行标记为“逻辑删除”，并不会立即回收磁盘空间。底层存储引擎（如 InnoDB）会保留这些页（page），留待后续 INSERT 复用，避免频繁分配/释放物理块带来的开销。所以你看到 du -sh 或数据库监控里表空间文件大小没变，完全符合预期。
InnoDB 表空间收缩必须显式触发 OPTIMIZE TABLE
想真正释放磁盘空间，得让 InnoDB 重建表并丢弃空闲页。最常用方式是执行：
OPTIMIZE TABLE `your_table_name`;
注意这会引发全表锁（MySQL 5.6+ 对普通表是 online DDL，但仍有短暂阻塞；MySQL 8.0 在某些场景下支持更轻量的 ALTER TABLE ... FORCE 或 ALTER TABLE ... ALGORITHM=INPLACE）。生产环境务必避开高峰，并确认有足够临时空间（它会先建新表，再原子替换）。
-
OPTIMIZE TABLE实际等价于ALTER TABLE ... ENGINE=InnoDB（对 InnoDB 表） - 如果表有全文索引或使用了压缩页，
OPTIMIZE还会重新组织索引结构 - 对大表（>10GB），该操作可能耗时数分钟到小时，期间写入会被延迟
替代方案：TRUNCATE 比 DELETE 更彻底，但不可回滚
如果你本意就是清空整张表，TRUNCATE TABLE 是更好的选择——它直接释放数据页、重置 AUTO_INCREMENT、不走事务日志，也不触发 DELETE 触发器。但注意：
-
TRUNCATE是 DDL，无法在事务中回滚（MySQL 中一旦执行即提交） - 部分存储引擎（如 MyISAM）支持快速清空，但 InnoDB 仍需重建内部段
- 权限要求更高：
DROP权限而非仅DELETE
长期预防：合理设置 innodb_file_per_table 和定期归档
默认开启的 innodb_file_per_table=ON（MySQL 5.6+ 默认）能让每张表独占一个 .ibd 文件，这样 OPTIMIZE 才能真正缩小单个文件。若关闭，所有表共用系统表空间 ibdata1，即使删光数据也无法缩容——此时唯一办法是导出 + 重建整个实例。
另外，高频删旧数据的场景（如日志表），建议按时间分区（PARTITION BY RANGE），用 ALTER TABLE ... DROP PARTITION 快速释放空间，比逐行 DELETE 高效且可预测。
真正难处理的是那些删了又反复插入、导致页碎片严重但总量没变的表——这种情况下，OPTIMIZE 不是“要不要做”，而是“什么时候做、怎么最小化影响”的问题。
