INSERT会引发页分裂，因B+树要求按键值严格排序插入，目标页满时必须拆分；自增主键可大幅降低分裂频次，而UUID等随机主键则几乎每次插入都可能触发分裂。
INSERT 操作不会触发索引“重建”，但一定会触发索引页的定位、插入和可能的分裂——这是 B+ 树索引的正常维护行为，不是故障，也不是配置错误。
为什么 INSERT 会引发页分裂而不是直接追加
因为聚集索引（或任何 B+ 树索引）要求叶子节点按键值严格排序。新行不能简单“追加到末尾”，而必须插入到逻辑顺序对应的位置。当目标页已满，InnoDB 或 SQL Server 就必须拆分它。
- 自增主键（
BIGINT IDENTITY）下，新行大概率落在最后一页末尾 → 分裂极少 -
UUID或VARCHAR(36)主键下，新值散落在整个键空间 → 几乎每次插入都需定位、检查、分裂 - 复合索引中把低频变化字段放最左（如
(status, created_at)），相同status的大量新行挤在同一页 → 快速填满并分裂
哪些 INSERT 场景会让分裂频率飙升
分裂本身不报错，但高频分裂会快速抬高 avg_page_space_used_in_percent（低于 75% 即预警）和 Data_free（持续 > 表大小 20% 就危险）。真正放大问题的是写入模式：
- 单条
INSERT INTO t VALUES (...)循环执行：每条都是独立事务 + 独立索引维护 - 触发器内嵌
INSERT或UPDATE：1 次业务写入 → 触发 N 次额外索引更新 - 用
NEWID()（SQL Server）或UUID_SHORT()（MySQL）生成主键：彻底打乱插入局部性 - 批量导入时未禁用外键/约束/索引：每行都要校验并更新所有二级索引
填充因子（FILLFACTOR）对 INSERT 分裂的实际影响
设 FILLFACTOR = 80 并不能“防止分裂”，反而在 OLTP 场景中常起反作用：
- 它只在首次建索引或重建时生效，后续插入照样填满空闲空间，填满后下一次仍分裂
- 每页少存 20% 行 → Buffer Pool 要加载更多页 → 缓存命中率下降 → 查询反而更慢
- 对
VARCHAR或GUID主键无效：空闲空间无法缓解逻辑位置跳跃问题 - 推荐做法：
FILLFACTOR = 0（即 100%），靠主键设计规避分裂，而非靠预留空间硬扛
如何验证当前分裂是否已造成实质性影响
别看日志有没有报错，要看运行时指标是否异常漂移：
- MySQL：
SHOW TABLE STATUS LIKE 't'查Data_free；用sys.schema_index_statistics看rows_inserted与io_read_requests比值是否恶化 - SQL Server：
SELECT * FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('t'), NULL, NULL, 'DETAILED')关注avg_page_space_used_in_percent和page_count增长斜率 - 共性信号：同样数据量，
innodb_buffer_pool_reads显著上升，但innodb_buffer_pool_read_requests未同比增加 → 说明碎片导致物理读跳变增多
页分裂不是 bug，是 B+ 树活着的证明；但频繁分裂背后，往往是主键设计、写入节奏或触发器滥用这些可干预的点。真正要调的不是填充因子，而是数据落盘的“顺序感”。
