结论先行
InnoDB 里 DELETE 是「标记删除 + 空间回收进 free list」，不是「物理抹掉文件里的字节」。删掉 1.7 亿行后 .ibd 文件大小几乎不变，这不是 bug、不是磁盘没刷、更不是数据没删掉——被删行占的 16KB 页被挂进了 InnoDB 的 free page list，等着下一次 INSERT 重用。真正的回收只有三条路：让 free page 被后续写入自然重用（免费）、ALTER TABLE ... FORCE / OPTIMIZE TABLE 重建表（要 2x 磁盘和几小时）、或一开始就用 RANGE 分区 + DROP PARTITION 物理删除（连这个问题都不会有）。下面用一次真实的「删了数据、磁盘却还在涨」事件把机制讲透。
一、现象：删了 1.7 亿行，df 看磁盘一点没少
场景：一套交易明细系统，核心表 t_trade_detail（InnoDB、MySQL 8.0.32、innodb_file_per_table=1、innodb_page_size=16KB），2.1 亿行、.ibd 单文件 86GB。业务规则是「保留 180 天」，凌晨任务跑：
DELETE FROM t_trade_detail
WHERE trade_time < '2024-05-01'
LIMIT 200000; -- 循环批删，共 850 批
批删总耗时 42 分钟，删掉 1.70 亿行（占全表 81%）。业务方看着行数从 2.1 亿掉到 4000 万，以为空间也该跟着掉，结果 df -h 一看数据目录还是 86GB，运维当场怀疑「是不是 DELETE 没生效」。
我拉了 information_schema.tables 和 SHOW TABLE STATUS 对账，数据其实是这么变的：
| 指标 | 删前 | 删后 |
|---|---|---|
| rows | 210,000,000 | 40,200,000 |
| data_length（已用数据页） | ~78 GB | ~19 GB |
| data_free（空闲可重用页） | 1.2 GB | 61 GB |
| .ibd 文件（df） | 86 GB | 86 GB（不变） |
关键就在 data_free 从 1.2GB 飙到 61GB：那 61GB 不是「没删掉的数据」，而是已经还给 InnoDB、随时可被复用的空闲页。文件不缩，是因为 .ibd 的大小等于「曾经分配过的页 × 16KB」，free page 仍然占着文件空间。
二、原理：InnoDB 的「删除」到底做了什么
很多人把 DELETE 理解成「从文件里挖掉那几行」，实际上 InnoDB 分了两件独立的事，而「缩文件」两件都不做：
1) 行删除 = 打删除标记，页不立刻释放。 被删的行先被标记为 delete-marked，空间留在原页里。只有当一个页里的行全部被删空、且该页不在任何未决 MVCC 版本链上时，这个 16KB 页才会被整体摘下，挂进 free page list。
2) purge 线程只负责清 undo 版本，不负责缩文件。 被删行对应的旧版本记录进 undo log，purge 线程在确认没有更早的 MVCC 读事务还依赖这些版本后，才回收 undo。purge 管的是「版本链能不能断」，和「.ibd 文件多大」是两码事——这也是为什么长事务会同时卡住 purge 和空间重用（社区里已有专文讲 history list，本篇不展开）。
3) free page list 的设计意图是「重用比再分配快」。 一个 16KB 页一旦分配过，就带着它所在的 segment 元数据；把它留着等下一次 INSERT 直接填，比走「向 OS 申请新页 → 初始化页头 → 挂进 B+ 树」的完整分配路径便宜得多，还省一次 doublewrite。所以 InnoDB 故意不缩文件——在「只删不插」的表上这看起来像 bug，在「删了又插」的活表上这是优化。
一句话：.ibd 大小 = 历史峰值占用，而不是当前行数。free page 是「预付费」的内存/磁盘额度，不是垃圾。
三、具体做法：确认碎片、判断要不要回收、再选回收手段
第 1 步，先量化碎片率，别急着重建。 碎片率用 data_free / (data_length + data_free) 衡量：
SELECT table_name,
ROUND(data_length/1024/1024/1024, 2) AS used_gb,
ROUND(data_free/1024/1024/1024, 2) AS free_gb,
ROUND(data_free/(data_length+data_free)*100, 1) AS frag_pct
FROM information_schema.tables
WHERE table_schema='trade' AND table_name='t_trade_detail';
我们删后 frag_pct = 61/(19+61) = 76%——这个比例高到必须处理；但如果是 10%~20%，放着不管，让 free page 自然重用就行。
第 2 步，如果表还在高频写入，优先「免费回收」：什么都不做。 只要后续 INSERT 持续，free page 会被逐页填回，data_free 会自己降下来。实测删后一周内，t_trade_detail 的 INSERT P99 从 6.1ms 降到 3.2ms（free page 直接重用，省了页分配 + doublewrite），data_free 从 61GB 自然回落到 22GB。这是最便宜也最正确的路径。
第 3 步，确认「只删不插」且碎片率 > 40%，才做物理重建。 在线重建用 pt-online-schema-change（避免 ALTER ... FORCE 的 MDL 长锁窗口），本质等价于：
-- 逻辑等价：建影子表 → 触发器拷数据 → RENAME 切换
ALTER TABLE t_trade_detail ENGINE=InnoDB; -- 或 FORCE，重建并真正 truncate 文件
实测：86GB 表重建耗时 3h12min，期间需要额外 86GB 磁盘（影子表要装下全部存活数据）。OPTIMIZE TABLE 对 InnoDB 来说就是 ALTER ... FORCE 的别名，没有"只压缩不重建"的第三种模式——这点很多人被 MySQL 文档里那句 "reclaims unused space" 骗了。
第 4 步，事前设计：按时间 RANGE 分区，让过期数据物理消失。 如果这张表一开始就按 trade_time 做了 RANGE COLUMNS(trade_time) 分区，过期清理就是一句 ALTER TABLE t_trade_detail DROP PARTITION p202405;，0.6 秒、文件里对应分区直接消失、不产生 undo、不占 free list。社区里已有专文讲「日志表用 DROP PARTITION 替代 DELETE」，本篇只补一个被忽略的推论：分区表连「删除不缩表」这个问题都根本不存在，因为 DROP PARTITION 是物理删除而非逻辑删除。
四、踩过的坑 / 反直觉之处
- 「删了不缩」有时是好事，别为了缩而缩。 重建要 2x 磁盘 + 几小时 + 影子表 IO，如果表还在高频写，free page 会被自然吃回去，重建纯属浪费——我见过一次为「磁盘看着大」就重建 86GB 表，结果一周后又长回去，白付了 3 小时 IO。判断标准是「这张表还会不会插」，不是「free_gb 大不大」。
OPTIMIZE TABLE不是「压缩」，是「重建」。 它对 InnoDB 的行为和ALTER ... FORCE完全一致，会拿 MDL、会占 2x 磁盘、会重写全部数据。在业务高峰期裸跑OPTIMIZE等于一次在线 DDL，务必走 pt-osc 或 gh-ost。innodb_file_per_table=0（共用表空间）时，删表都收不回空间。 所有表挤在ibdata1里，.ibd根本不独立，DROP TABLE 也只是把空间标记为可重用，文件永远只增不减。生产务必确认innodb_file_per_table=1，否则「回收」无从谈起。data_free大 ≠ 要重建，free page 重用是免费的。 反直觉的核心在于：把 61GB free page 当成「垃圾」去清，恰恰丢掉了「省页分配 + 省 doublewrite」的红利。正确心智模型是——free page 是预付费额度，用得上就是资产，用不上且只删不插才是负债。- 重建期间磁盘要预留 2x，别只留 1.5x。 影子表要装下全部存活数据 + 原有文件，86GB 表至少 172GB 可用；我们一次重建就是因为只留了 1.3x，卡在「磁盘不足」上被迫中断，白跑 2 小时。
五、结论与可复用清单
- 心智模型：InnoDB 的 DELETE 是「标记删除 + 页回收进 free list」，
.ibd大小 = 历史峰值占用，不等于当前行数；「删了不缩」是设计，不是 bug。 - 先量化再动手：
data_free/(data_length+data_free)< 40% 且表仍在高频写 → 什么都不做，让 free page 自然重用（还白赚 doublewrite 红利）；> 40% 且只删不插 → 才考虑重建。 - 重建走在线工具：
pt-online-schema-change/gh-ost，等价ALTER ... FORCE，预留 2x 磁盘，避开业务高峰。 OPTIMIZE TABLE=ALTER ... FORCE（对 InnoDB），没有"只压缩"模式，别在高峰期裸跑。- 确认
innodb_file_per_table=1，否则删表都收不回空间。 - 事前设计：按时间的 RANGE 分区表用
DROP PARTITION清理，物理删除、0.6s、无 undo、无 free list、无「不缩表」问题——比事后回收干净一个量级。
（本篇与社区已有多篇 InnoDB 主题互补：长事务/history list、DROP PARTITION 归档、doublewrite 各有专文；本篇聚焦「删除后的空间生命周期与回收手段」这一独立切面，引用了分区归档那篇作为「事前设计」的支撑。）