在进行大批量数据插入操作时，非聚集索引往往会成为性能瓶颈——这究竟是为什么？简单来说，暂时禁用这些索引能够显著提升写入速度：跳过每行插入过程中的索引页写入、统计信息更新以及唯一性检查，把多次随机I/O合并为一次批量重建。不过，这一策略仅适用于离线导入场景，事后必须使用REBUILD命令恢复索引，同时还需小心统计信息可能滞后带来的影响。
非聚集索引在批量INSERT时如何增加写入开销
非聚集索引并不存储完整的行数据，但每当插入一行记录时，SQL Server都必须同步更新所有相关非聚集索引的叶子节点。这意味着每条实际插入的记录会触发多次随机I/O（每个非聚集索引一次），而非单次顺序写入。当一张表拥有5个以上非聚集索引时，写入放大效应会变得非常显著——每次插入就像同时处理五六份独立的文档，效率自然大打折扣。
为什么禁用非聚集索引能显著提速
禁用非聚集索引（ALTER INDEX ... DISABLE）后，SQL Server会跳过所有索引维护逻辑：不写入索引页、不更新统计信息、不检查唯一性约束（除非是唯一索引且启用了强制检查）。实测中，千万级数据的导入场景下，禁用3个非聚集索引能将耗时从48秒压缩到11秒，效果立竿见影。但需要注意的是：DISABLE操作不会释放空间，索引处于不可用状态，后续查询会失败或回退到堆扫描。
- 仅适用于离线导入或维护窗口，生产环境中的实时写入不可用
- 禁用后必须使用
REBUILD而非REORGANIZE恢复，后者无法重建已处于DISABLED状态的索引 - 唯一非聚集索引禁用前，需确认业务可以容忍短暂缺失的唯一性校验
BULK INSERT和SqlBulkCopy为何默认绕过非聚集索引开销
BULK INSERT和SqlBulkCopy在添加TABLOCK提示时，会以最小日志模式运行，并自动暂停非聚集索引维护（除非显式指定KEEP_INDEXES）。它们并非“忽略”索引，而是将索引更新延迟到整个批次提交后进行批量重建——相当于把多次小更新合并为一次大排序与构建，显著降低B+树分裂和页拆分频率。
- 若未添加
TABLOCK，BULK INSERT仍会走行锁路径，非聚集索引更新照常发生 SqlBulkCopy.BatchSize设置为5000–10000较为均衡；过小（如100）会导致事务频繁提交，过大（如10万）则容易触发内存溢出或锁升级- 目标表若包含计算列或过滤索引，
KEEP_INDEXES可能失效，需要提前评估
容易被忽略的隐式开销：统计信息自动更新
即使禁用了非聚集索引，SQL Server在完成大批量INSERT后仍可能触发异步统计信息更新（auto_update_statistics = ON），这会导致额外的采样扫描和CPU争用。更隐蔽的是，某些非聚集索引虽然被禁用，但其统计信息对象仍然存在，且UPDATE STATISTICS命令默认包含DISABLED索引——结果就是导入刚结束，后台便开始扫描表更新统计信息，拖慢后续查询的响应速度。
- 导入前临时关闭：
ALTER DATABASE [db] SET AUTO_UPDATE_STATISTICS OFF - 导入后手动更新关键索引：
UPDATE STATISTICS t WITH SAMPLE 20 PERCENT, COLUMNS - 切勿依赖“导入完立刻查询”，统计信息滞后可能导致执行计划劣化
非聚集索引拖慢性能的本质并非“索引存在”，而是“每行都需要实时维护”。真正节省时间的做法，是把维护动作从“每行一次”压缩成“每批一次”甚至“全程零次”，再选择合适的时机批量补上——这种节奏上的差异，才是性能的分水岭。
