DELETE不释放磁盘空间是InnoDB正常设计行为，仅逻辑标记删除（设delete_mask位）、更新空闲链表，整页仍保留在.ibd文件中供复用；真正释放需OPTIMIZE TABLE或ALTER TABLE ENGINE=InnoDB重建表。
DELETE 不释放磁盘空间是 InnoDB 的正常行为，不是配置错误或 bug。它只做逻辑标记，不删物理页，更不会缩小 .ibd 文件。
为什么 DELETE 后 du -sh table.ibd 完全不变
InnoDB 的 DELETE 本质是把行头的 delete_mask 位设为 1，并更新页内空闲链表。整块 16KB 数据页仍保留在文件中，供后续 INSERT 复用。
-
Data_length不降：它统计的是“有效数据页”的累计大小，已删行不计入，但页没丢，所以值基本不动 -
Data_free反而可能变大：代表“可复用但未归还 OS”的页数，不是已释放空间 -
SELECT COUNT(*) = 0和df -h看不到变化，是完全预期的结果
OPTIMIZE TABLE 和 ALTER TABLE t ENGINE=InnoDB 到底做了什么
两者在 InnoDB 表上效果一致：重建表。核心步骤是新建空 .ibd → 拷贝所有未被标记删除的有效行 → 原子替换文件 → OS 回收旧文件。
- 执行后
Data_free归零，.ibd文件大小回落到实际数据+索引占用水平 - MySQL 5.7+ 中
OPTIMIZE TABLE t等价于ALTER TABLE t FORCE，默认走ALGORITHM=INPLACE（但仍需锁） - 不写 binlog（ROW 格式下），主从
.ibd大小会不一致；RDS 等托管服务可能禁用或转到只读副本执行
执行前不检查这三件事，大概率失败
跳过任意一项，都可能触发 ERROR 1034、锁死业务或中途崩溃。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 查磁盘余量：
df -h /var/lib/mysql，剩余空间 ≥SHOW TABLE STATUS LIKE 't'\G中的Data_length（建议留 1.5 倍冗余） - 查长事务：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 600，有结果必须先KILL - 确认基础条件：
SHOW CREATE TABLE t\G输出含ENGINE=InnoDB，且实例级参数innodb_file_per_table = ON
什么情况下不该直接跑 OPTIMIZE TABLE
对活跃大表盲目重建，代价常远高于收益。
- 表 >100GB 或磁盘使用率 >85%：临时文件极易写满，锁表时间不可控
- 只删部分数据？优先用
mysqldump --where="create_time > '2025-01-01'" db t > t_recent.sql导出再重建导入 - 整表清空且允许停机？用
TRUNCATE TABLE t——它删文件再建新.ibd，立刻释放空间（但不支持WHERE，外键子表上会报ERROR 1701） -
Data_free高 ≠ 必须优化——它本就是为写入性能预留的缓冲空间；重建的关键，从来不是“碎片数字”，而是你是否真需要把空间还给操作系统，以及能否承受重建过程中的 I/O 压力和锁开销
真正释放空间必须物理重建表，没有捷径。最容易被忽略的点是：Data_free 高本身不是问题，它只是说明“当前有大量可复用页”，不代表磁盘真的被浪费了；而重建操作的风险（锁、I/O、磁盘爆满）往往比“多占几个 GB”更值得警惕。
