应优先用alter table engine=innodb而非optimize table，因前者兼容性更好、云环境支持更广，且二者本质均为重建表以清理碎片、重排页序并释放空间。
MySQL索引维护和碎片整理不是“可做可不做”的附加项，而是保障查询效率、磁盘空间与缓冲池利用率的关键运维动作。尤其在InnoDB引擎中，频繁增删改后，B+树页分裂、空洞残留、物理顺序错乱会直接拖慢范围扫描、覆盖索引等高频操作。
怎么判断表或索引有碎片？
别靠猜测，用数据说话：
- 查
information_schema.TABLES中的DATA_FREE字段：单位字节，代表未被复用的空闲空间。若DATA_FREE / (DATA_LENGTH + INDEX_LENGTH) > 0.15（即超15%），说明碎片较重；超过30%建议立即处理。 - 看
sys.schema_table_statistics（需启用sys schema）：重点关注avg_page_length和data_length / table_rows比值，明显偏低（如＜1000字节/行）常意味着页填充率差、碎片高。 - 对比物理文件大小：进入MySQL数据目录，检查
.ibd文件大小是否远大于DATA_LENGTH + INDEX_LENGTH之和——多出来的就是“躺在磁盘上却无法被回收”的碎片空间。
OPTIMIZE TABLE 和 ALTER TABLE，选哪个？
二者本质都是重建表+索引，但适用场景不同：
- OPTIMIZE TABLE：对单表一键执行，自动完成“创建新表→按主键顺序拷贝数据→重建所有索引→替换旧表”。InnoDB下基本为Online DDL（只短暂锁元数据），适合中小表（
-
ALTER TABLE ... ENGINE=InnoDB或ALTER TABLE ... ALGORITHM=INPLACE：更可控。例如加
ALGORITHM=INPLACE, LOCK=NONE可最大限度减少阻塞；也可分步操作（先删索引再加，避免主键重建连带二级索引重刷）。适合大表或需要精细控制锁级别的场景。
碎片整理后为什么.ibd没变小？
这不是失败，而是InnoDB的设计特性：
- InnoDB默认不会把释放的空间归还给操作系统，而是保留在表空间内供后续插入复用。所以
DATA_FREE下降、查询变快，但.ibd文件体积不变是正常现象。 - 真要收缩物理文件，必须配合
innodb_file_per_table=ON（默认开启），且执行OPTIMIZE TABLE后，MySQL才会尝试截断.ibd末尾空闲段。若仍不释放，可临时关闭该参数并重启mysqld（仅限极端情况，慎用）。
日常怎么预防碎片越积越多？
治标更要治本：
- 写入时尽量使用自增主键，避免UUID等随机值导致页分裂加剧；
- 删除大批量历史数据后，不要跳过碎片整理步骤；
- 对日志类、流水类高频变更表，设置自动化巡检脚本，每周扫描
DATA_FREE > 100MB或碎片率＞10%的表并告警； - 合理使用分区表（如按时间分区），让过期分区可直接
DROP PARTITION，物理空间即时回收，比DELETE+OPTIMIZE高效得多。
