聚簇索引页分裂拖慢INSERT/UPDATE，因每次需同步申请新页、拷贝约一半数据、更新父节点指针，且必须写redo log和加锁；高并发下多线程争同一B+树节点锁，吞吐量骤降。
聚簇索引页分裂为什么会拖慢INSERT/UPDATE
因为每次分裂都要做三件事：申请新页、拷贝约一半数据、更新父节点指针——这些全是同步阻塞操作，且必须写redo log和加锁。在高并发插入场景下，多个线程卡在同一层B+树节点上等锁，吞吐量直接掉下来。
自增主键也分裂？那一定是填充因子或页利用率出了问题
自增主键本身能保证顺序追加，但以下情况仍会触发分裂：
-
FILLFACTOR被设为低于100（比如80），人为制造页内空洞，反而让本可填满的页提前分裂 - 表里存在大量
UPDATE导致行变长，原页装不下，被迫迁移整行到新页（即使主键有序） - 事务长时间未提交，旧版本数据（MVCC历史记录）占满页空间，新插入无处落脚
- Buffer Pool太小，页频繁换入换出，导致
change buffer无法有效缓存二级索引变更，间接加剧聚簇索引页压力
如何确认当前分裂是否异常高频
别只看DATA_FREE，它对InnoDB几乎没参考价值。真正有效的信号是：
- 查询
sys.schema_table_statistics_with_buffer中rows_affected与inserts比值持续＞1.5，说明每条INSERT平均引发多次页级操作 -
SHOW ENGINE INNODB STATUS里的Pages split计数在1分钟内增长＞50次 -
INFORMATION_SCHEMA.INNODB_METRICS中dml_pages_split指标突增，同时buffer_pool_hit_rate跌破90% - 用
SELECT avg_page_space_used_in_percent FROM sys.dm_db_index_physical_stats(...)（注意：这是SQL Server语法，MySQL需改用INFORMATION_SCHEMA.INNODB_BUFFER_PAGE结合page_type='INDEX'估算）发现聚集索引页平均填充率长期＜75%
避免分裂的关键不是“预留空间”，而是控制插入局部性
低FILLFACTOR在OLTP里基本是负优化：它让每页少存20%行，意味着更多页要进Buffer Pool，缓存效率反降。更有效的做法是：
- 强制用
BIGINT AUTO_INCREMENT作聚集键，业务字段（如订单号）走唯一二级索引 - 若必须用时间相关业务主键，构造
CHAR(14)格式如'20260904123456'，而非VARCHAR(50)随机字符串 - 批量插入时控制单批≤5000行，避免单次操作撑爆一个页并连锁触发多层分裂
- 对写密集表，关闭
innodb_adaptive_hash_index，减少分裂时HASH索引重建开销
OPTIMIZE TABLE都管用。 
