自增主键不能避免页分裂，但可通过调低innodb_fill_factor、批量插入、优化锁模式及重建索引来降低其频率和代价；需监控Innodb_page_splits与Innodb_page_merge_attempts指标验证效果。
自增主键本身不能避免页分裂，但能大幅降低其频率和代价；关键在于控制页填充率、批量写入节奏和锁模式配合。
为什么AUTO_INCREMENT主键仍会触发页分裂
B+树叶节点有固定大小（默认16KB），即使插入递增ID，当当前最右叶节点写满后，InnoDB必须分裂——这不是设计缺陷，而是B+树维持平衡的必然行为。常见误判是“自增就绝对不裂”，实际中innodb_page_splits指标在高并发插入时仍会明显上升。
- 页默认填充到约93.75%（预留1/16空间）即触发分裂，不是100%才裂
- 单条
INSERT INTO t VALUES ()每次都要检查页剩余空间，频繁触发分裂判断逻辑 - 事务未提交时，页无法被purge线程回收空闲空间，间接抑制后续合并机会
调低innodb_fill_factor让页“留白”
该参数控制新建索引页的初始填充比例，默认100表示填满。设为85意味着叶节点只存85%数据，预留15%空间缓冲后续自增插入，直接降低分裂概率。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 动态生效：
SET GLOBAL innodb_fill_factor = 85，但仅对后续CREATE TABLE或ALTER TABLE ... FORCE重建的索引生效 - 已有表必须执行
ALTER TABLE t ENGINE=InnoDB或ALTER TABLE t FORCE才能应用新填充率 - 低于75会显著增加磁盘占用和缓冲池压力，不建议无监控盲目下调
用批量INSERT代替单行AUTO_INCREMENT
逐条插入时，每条记录都走一次页定位→空间检查→可能分裂流程；而批量插入能把多条记录“塞进同一轮页检查”，摊薄分裂开销。
- 推荐单次
INSERT INTO t VALUES (),(),()...写入100–500行（受max_allowed_packet限制） - 避免在长事务中混杂大更新操作，否则会阻塞
purge线程，导致已删除记录的页空间无法及时回收用于合并 - 若业务强制单条写入，确认
innodb_autoinc_lock_mode=2（交错模式），减少自增锁争用，避免锁等待放大分裂延迟
监控innodb_page_splits与innodb_page_merge_attempts是否真实改善
优化效果不能靠QPS或平均延迟判断，必须盯住InnoDB底层指标：
- 执行
SHOW GLOBAL STATUS LIKE 'Innodb_page_splits'，观察数值是否下降 - 同时查
SHOW GLOBAL STATUS LIKE 'Innodb_page_merge_attempts'，上升说明空闲页开始被有效合并 - 对关键表运行
SELECT INDEX_NAME, N_RECS, PAGE_NO FROM information_schema.INNODB_INDEX_STATS WHERE TABLE_NAME='t'，估算单页记录数是否趋近理论值（如主键int型约700–900条/页）
页分裂无法彻底消除，但把innodb_page_splits从每秒几十次压到个位数，且innodb_page_merge_attempts同步上升，才是优化到位的信号。真正容易被忽略的是：已有表不重建索引，innodb_fill_factor再调也无效。
