索引插入性能下降主因是页分裂引发的 I / O 放大和碎片堆积；应优先使用单调递增主键、批量有序插入、合理设置 FILLFACTOR、用批量 INSERT 或 LOAD DATA INFILE 替代单行插入，并定期重建高碎片索引。
索引插入性能下降、写入变慢，往往不是因为数据量大，而是页分裂频繁导致的 I / O 放大和碎片堆积。核心在于让新记录尽量追加到索引页末尾，而非随机插入中间位置引发拆页、复制和链接更新。
按主键 / 聚簇键顺序插入数据
对于 InnoDB 等使用 B + 树聚簇索引的引擎，行物理存储顺序与主键逻辑顺序强绑定。若主键是自增整数（如AUTO_INCREMENT），新记录天然追加到 B + 树最右叶节点，几乎不触发页分裂。反之，用 UUID、随机字符串或业务无序 ID 作主键，极易造成叶节点反复分裂和填充率下降。
- 新增记录优先使用单调递增主键，避免随机值
- 批量导入时先 ORDER BY 主键 再 INSERT，尤其对非自增主键表
- 若必须用 UUID，可考虑 UUID_TO_BIN(UUID(), TRUE) 生成时间前置的二进制形式（MySQL 8.0+），提升局部性
合理设置填充因子（FILLFACTOR）
FILLFACTOR 控制索引页初始填充比例，预留空间供后续插入。但该值并非越高越好：设为 100% 虽节省空间，却使任何插入都可能分裂；设为 50% 则浪费一半空间且未必减少分裂——关键看写入模式。
- 仅对 高频随机插入 + 低更新率 的二级索引考虑调低 FILLFACTOR（如 70~85）
- 聚簇索引通常不建议手动设 FILLFACTOR，InnoDB 会自动管理页合并与分裂
- MySQL 中 FILLFACTOR 需在 CREATE INDEX 或ALTER INDEX时指定，且仅影响新建或重建索引
批量插入替代单行插入
单条 INSERT 触发一次索引定位 + 可能的页分裂；批量 INSERT（如INSERT INTO t VALUES (……), (……), (……)）在事务内复用相同页访问路径，显著降低分裂概率，并减少锁竞争和日志刷盘次数。
- 单次批量行数建议控制在 1000~5000 之间，过大易触发内存不足或长事务
- 避免在循环中拼接大批量 VALUES，改用预编译 + 参数化批量提交
- 对超 大数据 导入，优先用LOAD DATA INFILE，其内部优化了页分配策略
定期重建高碎片索引
即使做了前述优化，长期运行后二级索引仍可能因删除、更新产生空洞和逻辑碎片。当avg_fragmentation_in_percent > 30%（SQL Server）或Data_free / Data_length > 0.25（MySQL）时，应重建索引释放空间并重排页顺序。
- MySQL 中用 OPTIMIZE TABLE 或ALTER TABLE … FORCE重建聚簇索引及全部二级索引
- SQL Server 中用 ALTER INDEX … REBUILD，配合FILLFACTOR 参数预留增长空间
- 避免在业务高峰执行，重建期间索引不可用或仅支持并发 DML（取决于版本与选项）
