optimize table 能真正释放磁盘空间给操作系统，但仅当 innodb 表启用 innodb_file_per_table=on 且满足无长事务、磁盘空间充足等条件时，才会重建 .ibd 文件并缩小物理大小；否则仅标记空间可复用，文件尺寸不变。
OPTIMIZE TABLE 能否真正释放磁盘空间给操作系统？
取决于存储引擎和配置。InnoDB 表只有在启用 innodb_file_per_table=ON 时，OPTIMIZE TABLE 才可能将空闲页归还给操作系统；否则，空间仅在表内标记为可复用，.ibd 文件大小不会缩小。MyISAM 表的 .MYD 和 .MYI 文件则通常会明显变小。
执行 OPTIMIZE TABLE 前必须确认的三件事
避免锁表失败或无效操作：
- 检查存储引擎：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 'your_table'; - 确认
innodb_file_per_table是否开启：SHOW VARIABLES LIKE 'innodb_file_per_table';（值为ON才有效） - 验证权限：当前用户需同时具备该表的
SELECT和INSERT权限，缺一不可
OPTIMIZE TABLE 在 InnoDB 中实际做了什么？
它不是“整理碎片”的黑盒操作，而是等价于：ALTER TABLE your_table ENGINE=InnoDB;。这意味着：
- 创建全新的
.ibd文件，按聚簇索引顺序重新写入所有行 - 重建所有二级索引（辅助索引），但不是并行高效构建——键值按主键顺序插入，可能导致重建较慢
- 更新
mysql.innodb_table_stats和索引统计信息，影响后续查询优化器决策 - 不支持
ALGORITHM=INPLACE，全程需要独占元数据锁（MDL），表不可读写
比 OPTIMIZE 更轻量、更安全的替代方案
多数情况下，你并不需要 OPTIMIZE TABLE：
- 若只是想更新统计信息（提升执行计划质量），直接运行
ANALYZE TABLE your_table;即可，耗时短、几乎不锁表 - 若表空间持续膨胀且无法收缩，检查是否因长事务导致 purge 滞后，用
SHOW ENGINE INNODB STATUS查看History list length - 对日志类大表，优先考虑按时间分区 +
DROP PARTITION，比OPTIMIZE快几个数量级且不锁全表
真正需要 OPTIMIZE TABLE 的场景极少——通常是已确认 .ibd 文件远大于实际数据量（如 du -h 显示 50GB，但 SELECT SUM(data_length + index_length) 仅 12GB），且业务允许维护窗口期。
