索引碎片会降低查询性能，需通过DATA_FREE等指标判断是否重建；OPTIMIZE TABLE、ALTER TABLE ENGINE=InnoDB或单个索引增删是常用方法，须评估锁、空间与主从影响，并优先优化设计预防碎片。
MySQL索引碎片会影响查询性能，尤其在频繁增删改的表上。当数据页中存在大量空闲空间、页分裂严重或逻辑顺序与物理顺序不一致时，就产生了索引碎片。重建索引是清理碎片最直接有效的方式，但需结合场景选择合适方法，避免误操作影响业务。
判断是否需要重建索引
不能盲目重建。先用 SHOW INDEX 和 INFORMATION_SCHEMA.STATISTICS 查看索引基本信息，再通过 sys.schema_index_statistics 或 performance_schema.table_io_waits_summary_by_index_usage 辅助分析使用频率。更关键的是检查碎片程度：
- 对 InnoDB 表，执行 SELECT DATA_LENGTH, INDEX_LENGTH, DATA_FREE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'tbl_name'; —— 若 DATA_FREE 显著偏高（比如超过总索引大小的20%），说明存在明显碎片
- 用 OPTIMIZE TABLE 前可先运行 ANALYZE TABLE，观察 Cardinality 是否异常波动，间接反映统计信息失真，可能由碎片引起
常用索引重建方法及适用场景
MySQL 中“重建索引”本质是重建整个表或其聚集索引（主键）及二级索引。不同命令行为和影响范围不同：
-
OPTIMIZE TABLE tbl_name：适用于 MyISAM 和 InnoDB。InnoDB 下实际执行的是 ALTER TABLE ... FORCE（即重建表）。会锁表（8.0+ 支持在线 DDL 的部分操作，但仍需注意锁粒度），适合低峰期维护
-
ALTER TABLE tbl_name ENGINE=InnoDB;：显式重建表，效果同 OPTIMIZE TABLE，但语义更明确，便于脚本化。若原表已是 InnoDB，该操作仍会触发重建
-
ALTER TABLE tbl_name DROP INDEX idx_name, ADD INDEX idx_name (col1, col2);：仅重建单个二级索引，不涉及主键和表数据重排，耗时短、锁粒度小（支持 ALGORITHM=INPLACE），适合定位到具体低效索引时精准优化
重建过程中的关键注意事项
重建不是“一键修复”，需提前评估风险和资源消耗：
- 确保磁盘空间充足——重建期间需要额外空间存放新表，一般要求空闲空间 ≥ 当前表大小的 1.5 倍
- InnoDB 表重建会短暂阻塞写入（即使 ALGORITHM=INPLACE），读请求通常不受影响；如需完全无感知，可考虑主从切换+从库重建+切流方案
- 重
建后务必执行 ANALYZE TABLE 更新统计信息，否则优化器可能继续沿用旧的执行计划
- 避免在从库上直接 OPTIMIZE，可能导致主从延迟或复制中断（尤其开启 binlog_row_image=MINIMAL 时）
预防碎片比定期重建更重要
高频碎片往往暴露了设计或使用问题：
- 主键尽量用自增整型，避免用 UUID 或随机字符串作主键，减少页分裂
- 批量插入时按主键顺序组织数据；删除大量数据后，如长期不再写入，再考虑 OPTIMIZE
- 监控 innodb_file_per_table 是否启用（建议始终开启），便于单独管理表空间和识别碎片
- 用 pt-online-schema-change（Percona Toolkit）替代直接 ALTER，在大表上实现近似零停机重建
