索引插入性能下降主因是页分裂引发的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（取决于版本与选项）
