delete 不释放索引空间，因仅标记删除且不回收b+树页；optimize table 重建聚簇索引才能真正释放，或用 drop partition 秒级清理分区表。
DELETE 不动索引物理结构，只标记行删除 —— 所以索引页（.ibd 文件里的 B+ 树节点）根本没被回收，空间自然不释放。
为什么 DELETE 后 INDEX_LENGTH 几乎不变
InnoDB 的索引和数据共存于聚簇索引中，DELETE 操作只是把记录头的 delete_mask 置 1，并加入 purge 队列；B+ 树内部节点不会立刻合并或收缩，空闲页仍保留在文件里。即使你删光了整张表，SHOW TABLE STATUS 中的 INDEX_LENGTH 和 DATA_LENGTH 也几乎纹丝不动。
常见错误现象包括：
-
Data_free值飙升（比如从几 MB 变成几百 MB），说明页内碎片多，但整页未归还 OS - 执行
SELECT COUNT(*) FROM t返回 0，但du -sh t.ibd仍是 50GB - 监控显示磁盘使用率持续 >90%，而业务确认已清理千万级历史订单
OPTIMIZE TABLE 是唯一能真正回收索引空间的 SQL 命令
它不是“整理”，而是重建整个聚簇索引：逐行读取未被标记删除的有效数据，按主键顺序重写进新 .ibd 文件，旧文件丢弃。这个过程天然完成索引树重构、页合并、空闲页释放。
实操前必须确认三件事：
- 运行
SHOW VARIABLES LIKE 'innodb_file_per_table'，结果必须是ON；否则所有表共享ibdata1，重建无效 - 检查剩余磁盘空间 ≥ 当前
t.ibd大小 × 1.2；重建中途失败会导致表不可用 - 用
SELECT (DATA_FREE) / (DATA_LENGTH + INDEX_LENGTH) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't'计算碎片率；> 0.3 才值得跑
大表不能停机？别碰 OPTIMIZE TABLE，改用分区表 DROP PARTITION
这是目前唯一能秒级释放索引+数据空间、且不锁全表的方案，前提是建表时就用了 PARTITION BY RANGE (create_time) 这类策略。
例如：
ALTER TABLE orders DROP PARTITION p2023_q1;
这条命令会直接删除对应分区的整个 .ibd 文件（如果启用了 innodb_file_per_table），操作系统立刻回收空间，B+ 树结构也不受影响 —— 因为删的是独立子树。
注意：
- 事后加分区要
REORGANIZE，仍需移动数据，无法规避锁 -
TRUNCATE TABLE虽快，但清空整表，不满足“删部分”的业务场景 -
pt-online-schema-change --alter="ENGINE=InnoDB"可模拟在线重建，但要求磁盘余量 ≥ 表原始大小
容易被忽略的关键点
purge 线程卡住时，OPTIMIZE TABLE 即使跑完，实际释放量也可能极少——得先看 SHOW ENGINE INNODB STATUS\G 里 History list length 是否远高于 1000；有长事务未提交，或者 binlog_format = STATEMENT 且从库延迟，都可能拖住 purge。
