OPTIMIZE TABLE对独立表空间有效，但仅当innodb_file_per_table=ON、表位于独立.ibd文件且无长事务阻塞时，才能真正缩小物理文件大小；否则无法释放磁盘空间。
OPTIMIZE TABLE 对独立表空间真的有效吗
只有当 innodb_file_per_table=ON 且目标表确实落在独立 .ibd 文件中时，OPTIMIZE TABLE 才可能真正缩小物理文件大小。它不是“整理碎片”的万能开关——InnoDB 默认不把空闲页还给操作系统，哪怕逻辑上重建了表。你看到 Data_free 下降、.ibd 文件变小，前提是：表不在 ibdata1 里、没被长事务锁住、磁盘空间足够写新文件。
执行前必须确认的三件事
别跳过检查直接跑命令，否则大概率白等一小时还卡在 Waiting for table metadata lock：
-
SELECT @@innodb_file_per_table;必须返回1，否则所有 InnoDB 表都共享ibdata1，OPTIMIZE TABLE对磁盘空间完全无效 -
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't' AND TABLE_SCHEMA = 'db';确认ENGINE='InnoDB'且输出中含ROW_FORMAT（说明是独立表空间） -
ls -lh /var/lib/mysql/db/t.ibd查看文件是否存在且大小合理；若该路径下没.ibd文件，说明表仍在系统表空间，OPTIMIZE TABLE不会动ibdata1的尺寸
比 OPTIMIZE TABLE 更可靠的操作：ALTER TABLE ENGINE=InnoDB
OPTIMIZE TABLE t 在 InnoDB 上实际等价于 ALTER TABLE t ENGINE=InnoDB，但后者语义更明确、版本兼容性更好，尤其适合 MySQL 5.6+。它强制重建表，并按当前 innodb_page_size 和默认 ROW_FORMAT 分配页，有机会真实压缩 .ibd：
- 加
ALGORITHM=INPLACE可减少锁表时间：ALTER TABLE t ENGINE=InnoDB, ALGORITHM=INPLACE;，但外键约束或全文索引可能触发降级为 copy 模式 - 有外键时需临时关闭检查：
SET FOREIGN_KEY_CHECKS = 0;，执行完再设回1 - 确保磁盘剩余空间 ≥ 当前
t.ibd大小，否则会因写入失败中断 - 如果原表是
COMPACT格式而全局默认是DYNAMIC，重建后格式会变——这会影响大字段（TEXT/BLOB）是否内联存储，别在业务高峰期改
为什么 df -h 看不到磁盘空间增加
这不是命令失败，而是文件系统行为导致的错觉：OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 会原子替换旧 .ibd 文件，但 Linux 不会立刻将释放的块归还到全局可用池。真正有效的验证方式只有一种：
- 进数据库数据目录执行：
ls -lh /var/lib/mysql/db/t.ibd，对比操作前后大小变化 - 若
.ibd没变小，优先查SHOW PROCESSLIST是否有阻塞事务，再查information_schema.TABLES.DATA_FREE是否真有显著碎片（比如 >100MB） - RDS 或云数据库控制台显示的“磁盘使用率”是聚合统计，可能延迟更新或包含 binlog、relay log 等其他文件，不能直接对应单个
.ibd的收缩效果
