innodb的delete只做逻辑标记，不触发b+树物理结构调整，因此index_length几乎不变；真正释放索引空间需通过optimize table重建索引、drop partition删除分区或truncate/drop等物理操作。
为什么DELETE后INDEX_LENGTH几乎不变
因为InnoDB的DELETE只做逻辑标记：把记录头的delete_mask置1，加入purge队列等待异步清理。B+树的内部节点、叶子页不会被合并或收缩，空闲页仍保留在.ibd文件里——索引结构本身没动，INDEX_LENGTH自然纹丝不动。
常见错误现象包括：
-
SELECT COUNT(*) FROM t返回0，但du -sh t.ibd仍是50GB -
SHOW TABLE STATUS中Data_free飙升（比如从几MB涨到几百MB） - 云监控显示磁盘使用率>90%，而业务确认已删千万级历史数据
OPTIMIZE TABLE能真正释放索引空间吗
能，但有严格前提：OPTIMIZE TABLE本质是重建聚簇索引：读取所有未被标记删除的有效行，按主键顺序重写进新.ibd，旧文件丢弃。这个过程天然完成B+树重构、页合并、空闲页释放。
实操前必须确认三件事：
- 运行
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才值得跑
大表不能停机时怎么秒级释放索引空间
唯一可行方案是DROP PARTITION，前提是建表时用了分区策略，例如PARTITION BY RANGE (create_time)。
这条命令会直接删除对应分区的整个.ibd文件（如果启用了innodb_file_per_table），操作系统立刻回收空间，B+树结构也不受影响——因为删的是独立子树。
注意：
- 事后加分区要
REORGANIZE，仍需移动数据，无法规避锁 - 别在从库上直接跑
OPTIMIZE TABLE，它不走binlog，主从空间状态会不一致 -
ALTER TABLE ENGINE=InnoDB和OPTIMIZE TABLE效果一致，但同样锁表、耗临时空间
TRUNCATE和DROP为什么能立刻释放空间
TRUNCATE TABLE和DROP TABLE是物理操作：前者清空并重置表空间（相当于DROP+CREATE优化版），后者直接删除整个.ibd文件。它们都不依赖purge线程，也不受MVCC版本链影响，所以空间秒还OS。
但要注意：
-
TRUNCATE不可回滚，且会重置AUTO_INCREMENT - 对大表执行
TRUNCATE仍需短暂持有MDL锁，可能阻塞DML - 如果
innodb_file_per_table=OFF，TRUNCATE也无法缩小ibdata1
.ibd就还是那个大块头——这点在分区表和非分区表上表现截然不同，容易被忽略。
