禁用非聚集索引能显著提速，因其跳过每行插入时的索引页写入、统计更新与唯一性检查，将N次随机I/O压缩为1次批量重建；但仅适用于离线导入，需REBUILD恢复且须防统计信息滞后。
非聚集索引在批量INSERT时如何增加写入开销
非聚集索引本身不存储完整数据行，但每插入一行，SQL Server都必须同步更新所有相关非聚集索引的叶子节点——这意味着每条记录实际触发多次随机I/O（每个非聚集索引1次），而非单次顺序写入。尤其当表有5个以上非聚集索引时，写入放大效应会非常明显。
为什么禁用非聚集索引能显著提速
禁用非聚集索引（ALTER INDEX ... DISABLE）后，SQL Server跳过所有索引维护逻辑：不写索引页、不更新统计信息、不检查唯一性约束（除非是唯一索引+启用强制检查）。实测中，对千万级导入，禁用3个非聚集索引可将耗时从48秒降至11秒。但注意：DISABLE不释放空间，且索引处于不可用状态，查询会失败或回退到堆扫描。
- 仅适用于离线导入或维护窗口，生产环境实时写入不可用
- 禁用后必须用
REBUILD而非REORGANIZE恢复，后者无法重建DISABLED状态的索引 - 唯一非聚集索引禁用前需确认业务可容忍短暂的唯一性校验缺失
BULK INSERT和SqlBulkCopy为何默认绕过非聚集索引开销
BULK INSERT和SqlBulkCopy在TABLOCK提示下会以最小日志模式运行，并自动暂停非聚集索引维护（除非显式指定KEEP_INDEXES）。它们不是“忽略”索引，而是把索引更新延迟到整个批次提交后批量重建——相当于把N次小更新合并为1次大排序+构建，大幅降低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 - 切勿依赖“导入完立刻查”，统计信息滞后可能导致执行计划劣化
非聚集索引的拖慢本质不是“索引存在”，而是“每行都得实时维护”。真正省时间的操作，是把维护动作从“每行1次”压缩成“每批1次”甚至“全程0次”，再择机批量补上——这个节奏差，才是性能分水岭。
