索引碎片会降低查询性能，需通过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 中“重建索引”本质是重建整个表或其聚集索引（主键）及二级索引。不同命令行为和影响范围不同：
易优cms汽车车辆租赁源码1.7.2
下载
由于疫情等原因大家都开始习惯了通过互联网上租车服务的信息多方面，且获取方式简便，不管是婚庆用车、旅游租车、还是短租等租车业务。越来越多租车企业都开始主动把租车业务推向给潜在需求客户，所以如何设计一个租车网站，以便在同行中脱颖而出就重要了，易优cms针对租车行业市场需求、目标客户、盈利模式等，进行策划、设计、制作，建设一个符合用户与搜索引擎需求的租车网站源码。 网站首页
- 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，在大表上实现近似零停机重建
