insert本身不触发页分裂，但高频随机写入（如uuid主键、逐行插入）会频繁导致页分裂；自增主键可大幅减少聚簇索引分裂，但二级索引仍可能因非顺序值而分裂；批量插入需控制在500–1000行并排序，避免过大或过小批次；innodb_fill_factor不宜过高或过低，建议从80起压测调优。
INSERT本身不触发页分裂，但高频随机写入会放大分裂概率
页分裂不是INSERT语句的“副作用”，而是InnoDB在写入时发现目标页已满、且新记录无法追加到最右位置时的被动响应。真正导致频繁分裂的，是写入模式——比如用UUID()或NEWID()生成主键，或逐行执行INSERT INTO t VALUES (...)，会让新行不断“插队”进B+树中间页，每插几行就触发一次50-50数据迁移。
自增主键能避免大部分分裂，但二级索引仍可能中招
即使主键是BIGINT AUTO_INCREMENT，只要INSERT涉及更新或插入带非顺序值的二级索引（如name、status_id、created_at），这些索引页仍会因随机落点而分裂。常见错误包括：把user_id建为普通索引后批量按时间倒序导入订单，或在UPDATE中修改被索引的字段（如UPDATE t SET status = 2 WHERE id = 123），这比INSERT更易引发页内移动+页间迁移。
批量INSERT控制不当，反而加剧分裂和锁竞争
盲目堆高单条INSERT INTO t VALUES (),(),()...的行数，容易超出innodb_buffer_pool_size承载能力，引发长事务、锁等待甚至OOM；而拆成太多小批次（如每次10行），又让每批都独立触发索引维护，等效于把1次写入放大为N次小写入。实操建议：
- 单批控制在
500~1000行，显式用START TRANSACTION包裹 - 超百万级导入优先走
LOAD DATA INFILE，它绕过SQL解析层，性能高5–10倍 - 若必须用INSERT，源数据先按主键或高频连接字段排序（如
ORDER BY user_id），减少二级索引页命中抖动
innodb_fill_factor调太高反而坏事
设innodb_fill_factor = 99看似省空间，实际会让页“刚写满就裂”，尤其在非顺序写场景下分裂频次反升；设50又浪费缓冲池、拖慢查询局部性。它对自增主键表影响极小，只对二级索引或UUID主键表有效。生产中建议从80起步压测，观察Innodb_page_splits和慢查比例变化——别把它当成万能开关，更别在没监控指标前乱调。
最容易被忽略的是：页分裂不是孤立事件，它会连锁影响innodb_buffer_pool_reads、Handler_read_rnd_next和锁等待链。Data_free只是碎片的冰山一角，页内稀疏（一页只存40条而非80条）根本不会体现在这个字段里。
