MySQL InnoDB 不支持直接设置B+树索引填充因子，仅能通过预分配主键、页压缩、调整块大小及重建索引时临时应用innodb_fill_factor来间接影响页分裂；该变量对已有索引无效，且无法长期维持指定填充率。
MySQL 的 InnoDB 引擎不支持直接设置 B+树索引的“填充因子”（如 PostgreSQL 的 FILLFACTOR），所谓“调整填充因子”实际是通过控制页空间利用率来间接影响页分裂频率和范围查询性能。真正可操作的点只有两个：预分配主键空间 + 调整页压缩与块大小，而非在建索引时指定填充比例。
为什么不能用 ALTER INDEX SET FILLFACTOR？
MySQL 没有 ALTER INDEX ... FILLFACTOR 语法，也不暴露索引页填充率的运行时配置项。InnoDB 的页填充策略由引擎内部自动管理，依据插入顺序、键分布和页剩余空间动态决定是否触发页分裂。强行模仿其他数据库设填充因子，只会导致 SQL 报错或被忽略。
-
ALTER INDEX idx_name ON tbl_name FILLFACTOR=80;→ 直接报错ERROR 1064 -
innodb_fill_factor系统变量仅影响新创建的索引（非已有索引重建），且默认值为100，单位是百分比，但实际效果受限于键长和页结构，无法精确控制 - 该变量对已存在的索引完全无效，重启后也不会重填旧页
真正影响范围查询性能的页填充行为
范围查询（如 WHERE create_date BETWEEN '2025-01-01' AND '2025-12-31'）性能取决于叶子节点的物理连续性与链表跳转效率。当页频繁分裂后，叶子页在磁盘上变得离散，双向链表指针虽在逻辑上连通，但物理读取需多次随机 I/O —— 这才是范围查询变慢的根因，不是“填充率低”本身。
- 页分裂后，原页拆成两页，新页可能落在不同区（extent），破坏顺序性
- 监控关键指标：
Innodb_page_splits每小时超过 100 次，基本意味着范围扫描延迟开始上升 - 执行
SHOW GLOBAL STATUS LIKE '%innodb_page_splits%';查当前累计值，再对比历史基线
实操中唯一有效的“填充控制”手段
绕过不可控的自动填充逻辑，从源头减少分裂触发条件。核心思路是：让新记录尽量追加到末尾，避免中间插入导致页分裂。
- 使用自增
BIGINT主键，并预分配足够大的起始值：ALTER TABLE orders AUTO_INCREMENT = 100000000;，避免早期小 ID 写满页后反复分裂 - 对时间字段做范围查询的表，确保写入按时间递增（如订单表用
order_id自增，而非create_time作主键），否则时间乱序插入必然引发大量页分裂 - 建表时显式指定
KEY_BLOCK_SIZE = 8或COMPRESSION = 'zlib'，在页级压缩下，相同数据量占用更少空间，客观上延缓填满阈值（15/16 触发分裂） - 避免在高频写入表上建过多二级索引 —— 每个二级索引都是独立 B+ 树，每次 INSERT 都要更新所有索引页，分裂概率翻倍
重建索引时能做的有限干预
OPTIMIZE TABLE 或 ALTER TABLE ... FORCE 会重建聚簇索引和所有二级索引，此时 innodb_fill_factor 才起作用，但仅限本次重建过程。
- 先设全局变量：
SET GLOBAL innodb_fill_factor = 80;（注意：仅对后续新建/重建生效） - 再执行：
ALTER TABLE orders ENGINE=InnoDB;（触发重建） - 重建后，新页初始填充约 80%，但后续写入仍按默认逻辑增长，不会维持该比例
- 该操作锁表时间长，生产环境慎用；且对大表可能引发数小时不可写
真正难的是平衡：填充率留空太多，浪费空间、降低单页有效数据密度；填太满，又极易分裂。没有银弹，只有结合写入模式、数据生命周期和监控反馈持续微调 —— 尤其要注意，innodb_fill_factor 不是开关，而是重建时的一次性提示，别指望它长期生效。
