InnoDB的DELETE仅逻辑标记删除，不释放磁盘空间；真正释放需执行OPTIMIZE TABLE或ALTER TABLE t ENGINE=InnoDB重建表，以原子替换旧.ibd文件并由操作系统回收空间。
DELETE 不会立即释放磁盘空间，是 InnoDB 引擎的确定性行为，不是配置错误、没生效或 bug——它压根就不动 .ibd 文件大小。
DELETE 只改标记，不删页
InnoDB 的 DELETE 是逻辑删除：
- 把行头的
delete_mask位设为 1 - 更新该页内的空闲链表（
free list） - 整个数据页（默认 16KB）仍保留在
.ibd文件中，供后续INSERT复用
这意味着：
-
du -sh table.ibd输出完全不变 -
SHOW TABLE STATUS LIKE 't'\G中的Data_length几乎不降 - 即使
SELECT COUNT(*) = 0，文件尺寸也纹丝不动 -
Data_free值反而可能变大——它代表“可复用但未归还 OS”的页数，不是已释放空间
这不是泄漏，是为 MVCC、并发写入和写放大控制做的权衡。
真正释放空间必须重建表
只有物理重建才能让操作系统回收空间，核心手段就两个：
-
OPTIMIZE TABLE t -
ALTER TABLE t ENGINE=InnoDB
它们在 InnoDB 表上效果一致，本质是：
- 新建一个空
.ibd文件，按当前索引结构重排聚簇索引 - 逐行扫描原表，只拷贝未被标记删除的有效行
- 拷贝完成后，原子性地
DROP原表、RENAME新表 - 旧文件由 OS 层面真正回收
注意：OPTIMIZE TABLE t 在 MySQL 5.7+ 等价于 ALTER TABLE t FORCE，默认走 ALGORITHM=INPLACE（但仍需短暂 MDL 锁）。
安装、修复、更新或打包一个基于 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—— 否则 purge 线程卡住，重建也无法清理干净 - 确认基础条件：
SHOW CREATE TABLE t\G中含ENGINE=InnoDB，且实例级参数innodb_file_per_table = ON
innodb_file_per_table = OFF 时，所有表共用 ibdata1，删再多也永远不缩 —— 这个参数必须为 ON 才有释放可能。
什么情况下不该直接重建表
重建不是万能解药，尤其对活跃大表，风险常高于收益：
- 表 >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 压力和锁开销。
最容易被忽略的是：purge 被阻塞时（比如有长事务未提交），OPTIMIZE TABLE 即使跑完，实际释放量也可能远低于预期——得先看 SHOW ENGINE INNODB STATUS\G 里的历史列表长度。
