OPTIMIZE TABLE在phpMyAdmin中常无效，因需同时满足三条件：表为InnoDB引擎、innodb_file_per_table=1、无活跃长事务；否则不释放磁盘空间且难提升性能。
optimize table 在 phpmyadmin 里基本没用，除非你确认表是 innodb 且 innodb_file_per_table=1；否则磁盘空间根本不会释放，查询也难有提升。
怎么查表是不是真有碎片？别只看 Data_free
Data_free 对 InnoDB 不代表可回收空间，它只是「分配但未用」的页空间，可能全是预留的。真正该关注的是数据页填充率：
- 执行
SELECT table_name, round((data_length / (data_length + index_length)), 2) AS fill_ratio FROM information_schema.TABLES WHERE table_schema = 'your_db' AND engine = 'InnoDB' HAVING fill_ratio - 结果
fill_ratio越低（比如 - 如果
data_length + index_length很小（500MB）才值得动
为什么点了“优化表”却没效果？三个硬性前提缺一不可
phpMyAdmin 的“优化表”按钮只是发 OPTIMIZE TABLE，不校验任何条件。常见失效原因：
-
SHOW CREATE TABLE your_table返回不是ENGINE=InnoDB→ MyISAM 表能清碎片，但不能缩物理文件；Archive、Memory 等引擎根本不支持OPTIMIZE -
SELECT @@innodb_file_per_table返回0→ 所有 InnoDB 表都塞进共享表空间ibdata1，OPTIMIZE只重建内部页，ibdata1文件大小纹丝不动 - 表正在被长事务占用 →
SELECT * FROM information_schema.INNODB_TRX有活跃记录时，OPTIMIZE会卡住或失败，phpMyAdmin 页面容易超时假死
大表优化别在 phpMyAdmin 里点——用命令行加 nohup 更稳
超过 1GB 的表，在浏览器里点“优化表”风险很高：连接中断、页面卡死、后台还在跑但你误以为失败了。
- 登录服务器后执行：
nohup mysql -u root -p -e "OPTIMIZE TABLE your_db.your_table;" > /tmp/optimize.log 2>&1 & - 用
tail -f /tmp/optimize.log实时看进度，不依赖浏览器连接 - 如果表结构含
latin1字符集但 phpMyAdmin 连接用的是utf8mb4，OPTIMIZE过程中可能触发隐式转换，报错ERROR 1071 (42000)（索引长度超限），得先ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4再优化
真正麻烦的从来不是“怎么点”，而是判断“该不该做”——innodb_file_per_table 是开关，fill_ratio 是依据，长事务是拦路虎。三者没理清就点“优化表”，大概率白忙一场，还可能锁表拖慢线上请求。
立即学习“PHP免费学习笔记（深入）”；
