innodb_fill_factor不影响索引构建速度，仅控制建索引后INSERT/UPDATE时B+树页的预留空间；建索引走排序流程，与该参数无关。
为什么 innodb_fill_factor 对索引构建速度影响有限
它不加速建索引，只影响后续写入时的页填充率。建索引（ALTER TABLE ... ADD INDEX 或导入数据后创建）走的是排序构建流程，用的是内存+磁盘临时文件，和这个参数无关。它真正起作用的阶段是索引建好之后的 INSERT/UPDATE——控制每个 B+ 树页预留多少空闲空间，避免频繁页分裂。
-
innodb_fill_factor = 100：页填满，写入密集场景容易触发页分裂，产生碎片，但读性能略优 -
innodb_fill_factor = 80：默认值，留 20% 空间给后续更新，平衡写放大与空间利用率 - 低于 70 会明显浪费磁盘和内存（Buffer Pool），尤其对只读或低更新表毫无收益
真正能加快索引构建的几个实操点
MySQL 5.7+ 的 ALTER TABLE ... ALGORITHM=INPLACE 默认已优化，但仍有关键干预项：
- 建索引前关掉唯一性校验：
SET unique_checks = 0（仅适用于确认数据无冲突时） - 关掉外键检查：
SET foreign_key_checks = 0（确保没依赖变更） - 增大
sort_buffer_size和read_buffer_size（单次连接生效，建议设为 4M–16M，别盲目调太高） - 用
LOAD DATA INFILE导入后再建索引，比边插边建快 5–10 倍
注意：innodb_sort_buffer_size（5.7+ 引入）专用于排序建索引，可单独调高，但全局生效，别设超物理内存 10%。
innodb_fill_factor 应该在什么时机调？
不是建索引时调，而是预判表未来写模式再设：
- 日志类、时间序列表（持续追加，极少更新）→ 设
100，省空间、提升范围扫描效率 - 用户资料表（字段常更新，如
last_login_time）→ 设80–85，减少页分裂延迟 - 批量导入后立刻有高并发写 → 先设低值（如
75），等写压平稳再ALTER TABLE ... REBUILD调回
修改后需重建表才生效：ALTER TABLE t ENGINE=InnoDB 或 OPTIMIZE TABLE t（后者会锁表）。
容易被忽略的兼容性陷阱
innodb_fill_factor 是 InnoDB 表级配置，但不会自动继承到新分区、新二级索引，也不影响全文索引或空间索引：
- 分区表每个分区独立应用该值，建分区时未显式指定则用全局默认
-
CREATE INDEX语句无法指定 fill factor，只能靠表级配置兜底 - MySQL 5.6 不支持该参数，设了会静默忽略；5.7+ 才生效，且仅对 B+ 树索引页有效
- 如果用
mysqldump --single-transaction备份再恢复，新表会丢失原表的innodb_fill_factor设置
最稳妥的做法：在 CREATE TABLE 里显式声明 ROW_FORMAT=DYNAMIC + KEY_BLOCK_SIZE=0，再配合 innodb_fill_factor，否则某些压缩场景下参数可能被绕过。
