OPTIMIZE TABLE 在 InnoDB 中实际重建表，需锁表且不释放空间除非 innodb_file_per_table=ON；执行后 DATA_FREE 未降常因无碎片或共享表空间；GUI 工具不显示关键细节，应使用命令行验证。
OPTIMIZE TABLE 执行后没效果？先看它到底干了啥
optimize table 不是“一键清理碎片”的魔法按钮。在 innodb 表上，它实际等价于 alter table ... force —— 也就是重建表：创建新表、拷贝数据、删旧表、重命名。所以它必然加锁（mdl 锁），且全程阻塞写入。如果你在业务高峰期执行，会卡住所有 insert/update/delete；如果表很大，还可能触发磁盘空间不足（需要 2 倍原表大小的空闲空间）。
常见错误现象：OPTIMIZE TABLE 返回 OK，但 DATA_FREE 没变、查询速度也没提升。原因往往是：表本身没碎片（比如刚 TRUNCATE 过）、或用的是共享表空间（innodb_file_per_table=OFF），此时优化不释放磁盘空间到文件系统。
- 确认是否真有碎片：查
information_schema.TABLES的DATA_FREE字段，值 > 0 且显著（比如 > 表数据量的 20%）才值得优化 - 必须确保
innodb_file_per_table=ON（5.6.6+ 默认开启，但老实例可能关着） - 执行前检查磁盘剩余空间 ≥ 2 × 当前表
DATA_LENGTH + DATA_FREE
为什么 phpMyAdmin / DBeaver 界面里看不到执行结果细节
图形化工具通常只显示 SQL 执行的最终状态（如 Query OK, 0 rows affected），但 OPTIMIZE TABLE 的关键反馈藏在 MySQL 的“额外信息”里——比如是否真正重建了表、有没有跳过（因为表结构没变或引擎不支持）。这些信息只在命令行客户端（mysql CLI）的 STATUS 或 SHOW PROCESSLIST 中可见，GUI 工具基本不透出。
使用场景：你想确认优化是否生效，不能只信界面上那个绿色对勾。得去查系统表或观察磁盘变化。
- 执行后立刻查：
SELECT DATA_LENGTH, DATA_FREE, TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='your_table' - 对比执行前后
DATA_FREE是否归零（InnoDB）或明显下降（MyISAM） - MyISAM 表优化后，对应
.MYD文件大小应缩小；InnoDB 表则要看ibdata1或独立.ibd文件是否变小（仅当innodb_file_per_table=ON时.ibd会缩）
替代方案比 OPTIMIZE TABLE 更安全、更可控
线上表不能停写？OPTIMIZE TABLE 就不是首选。Percona Toolkit 的 pt-online-schema-change 或 MySQL 5.6+ 的在线 DDL（ALGORITHM=INPLACE）才是更现实的选择。它们能在不锁表的前提下重建，代价是耗时更长、CPU/IO 更高，但业务无感。
性能与兼容性影响：MySQL 8.0 对 OPTIMIZE TABLE 做了小幅优化（比如跳过已压缩页），但本质逻辑没变；而 pt-osc 要求主从延迟低、binlog 格式为 ROW，否则可能丢数据。
- 小表（OPTIMIZE TABLE，简单可靠
- 大表、不能停写：优先跑
pt-online-schema-change --alter "ENGINE=InnoDB" --execute - MySQL 8.0+ 且确认表无全文索引/外键依赖：可试
ALTER TABLE t ENGINE=InnoDB, ALGORITHM=INPLACE, LOCK=NONE（效果同优化，但更透明）
碎片清理不是定期任务，而是问题响应动作
很多人把 OPTIMIZE TABLE 当成“数据库体检”，每月定时跑一遍。这是错的。InnoDB 的碎片主要来自大量随机 DELETE + INSERT，或频繁 UPDATE 变长字段。如果你的表主要是追加写（如日志表），或者用了 ROW_FORMAT=COMPRESSED，碎片天然就少。
容易被忽略的一点：OPTIMIZE TABLE 会重置表的 auto_increment 值（基于当前最大 ID +1），如果业务依赖自增 ID 连续性，这个副作用可能引发下游解析失败。
- 不要写进定时脚本自动执行，除非你明确监控到某张表
DATA_FREE持续增长且影响查询性能 - 执行前备份该表的
SHOW CREATE TABLE和当前MAX(id)，以防AUTO_INCREMENT重置出问题 - 如果表启用了
innodb_page_cleaner且 I/O 压力不大，InnoDB 本身会后台合并页，日常无需人工干预
