MySQL DELETE 不释放磁盘空间是正常现象，因InnoDB仅标记行为空闲；OPTIMIZE TABLE仅在innodb_file_per_table=ON时有效释放空间，否则无效；执行需额外磁盘空间且锁表，大表慎用。
DELETE 后磁盘空间不释放是 MySQL 的正常行为
MySQL 的 DELETE 只是标记数据行为空闲，并不立即回收磁盘空间，尤其在 InnoDB 引擎下，表空间文件（如 ibdata1 或独立表空间 .ibd）不会自动收缩。即使删了 90% 的数据，du -sh 看到的文件大小几乎不变。
OPTIMIZE TABLE 能否真正释放空间？取决于表空间类型
OPTIMIZE TABLE 对 InnoDB 表的实际效果分两种情况：
- 使用共享表空间（
innodb_file_per_table=OFF）：操作无效，空间无法返还给操作系统，只做页整理 - 使用独立表空间（
innodb_file_per_table=ON，MySQL 5.6+ 默认）：会重建表、释放未用空间，并把空闲空间还给文件系统
执行前务必确认：SHOW VARIABLES LIKE 'innodb_file_per_table'; 返回 ON 才值得继续。
执行 OPTIMIZE TABLE 的实际代价和风险
它本质是「创建新表 + 拷贝数据 + 删除旧表」，期间需要额外磁盘空间（至少等于原表大小），且全程锁表（在 MySQL 5.6+ 中对 DML 是只读锁，但写操作会被阻塞）。
- 大表（>10GB）可能耗时数分钟到数小时，期间
INSERT/UPDATE/DELETE会排队等待 - 如果磁盘剩余空间小于原表大小，
OPTIMIZE TABLE会直接失败并报错：ERROR 1034 (HY000): Incorrect key file for table - 不建议在业务高峰期执行；可改用
ALTER TABLE t ENGINE=InnoDB;达到等效效果（更直观，语义更明确）
示例：
ALTER TABLE orders ENGINE=InnoDB;
替代方案：更轻量、更可控的空间回收方式
如果只是想快速释放空间又不敢动大表，优先考虑这些：
- 用
TRUNCATE TABLE替代大批量DELETE：立刻释放空间，且不走逐行标记逻辑 - 分批删除 +
ALTER TABLE ... ENGINE=InnoDB：比如先删老数据，再对小表执行重建，降低单次开销 - 检查是否有没清理的
ib_logfile*或过期 binlog：它们也占磁盘，但和DELETE无关 - 确认是否启用了
innodb_file_per_table—— 这是所有空间回收操作的前提，没开就别折腾OPTIMIZE
真正容易被忽略的是：哪怕开了 innodb_file_per_table，如果表之前建在共享空间里（比如老版本迁移过来没重建），.ibd 文件也不会自动生成，OPTIMIZE 依然无效。得先 ALTER TABLE t ENGINE=InnoDB ROW_FORMAT=DYNAMIC; 强制迁出。
