优化sql server批量插入需选择bulk insert或sqlbulkcopy工具，结合事务日志优化、索引策略调整和数据库配置，具体包括使用tablock提示、临时切换恢复模式为bulk_logged或simple、预排序数据、禁用非聚集索引与约束，并预分配文件空间，以减少日志、锁争用和i/o开销，显著提升大批量数据插入性能。
直接用单条 INSERT INTO ... VALUES (...), (...) 插入几千行，性能会断崖式下跌；真正高效的大批量插入，必须绕过常规语句路径，用 BULK INSERT、SqlBulkCopy 或分批事务 + 索引控制组合策略。
用 BULK INSERT 从文件导入（最快，但有路径限制）
这是 SQL Server 原生最快的批量导入方式，数据不经过网络协议栈，直接由 SQL Server 进程读取本地或 UNC 路径文件。但它要求文件对 SQL Server 服务账户可见，不能是客户端本地路径。
-
BULK INSERT必须配合TABLOCK提示，否则默认行锁会严重拖慢速度：BULK INSERT orders FROM 'D:\data\orders.csv' WITH (FIELDTERMINATOR = ',', ROWTERMINATOR = '\n', TABLOCK);
- 如果数据库恢复模式不是
BULK_LOGGED或SIMPLE，日志会全量记录，导致磁盘 I/O 暴涨；导入前建议临时切换：ALTER DATABASE yourdb SET RECOVERY BULK_LOGGED;
- CSV 文件字段含换行符、引号或 NULL 时，
FORMAT = 'CSV'（SQL Server 2017+）比手动写FIELDTERMINATOR更健壮，但需显式指定FIRSTROW跳过表头 - 别指望它自动类型转换——源字段类型必须严格匹配目标列，否则整批失败，错误信息只报“批量加载失败”，不提示具体哪一行哪一列
用 SqlBulkCopy 从 .NET 应用推送（最灵活，推荐日常使用）
当你无法把数据文件放到 SQL Server 机器上，或者数据来自内存对象（如 DataTable、DataReader），SqlBulkCopy 是唯一能接近 BULK INSERT 性能的选择。
- 务必设置
BatchSize（如5000），否则默认一次性提交全部行，容易触发内存溢出或事务日志撑爆：bulkCopy.BatchSize = 5000;
- 开启
EnableStreaming = true可避免把整个数据集加载进内存，适合超大数据流（但要求源实现IDataReader） - 列名映射必须显式做，尤其当源列顺序与目标表不一致时：
bulkCopy.ColumnMappings.Add("OrderDate", "order_date"); - 不要在
WriteToServer前手动开事务——SqlBulkCopy内部已用最小日志模式，加外部事务反而增加锁范围；如需一致性保障，应在调用前后用应用层事务包裹
用多值 INSERT + 分批事务（中等数据量，无额外权限要求）
当数据量在几万行以内、且你无法用 BULK INSERT 或 SqlBulkCopy（比如用 Python/PHP 等非 .NET 环境），这是最现实的折中方案。
- 每批最多拼
1000组VALUES，再多 SQL Server 解析器会明显变慢，且可能触发max text repl size或参数绑定限制 - 必须用显式事务包裹整批：
BEGIN TRANSACTION; INSERT INTO orders (...) VALUES (...), (...), ...; COMMIT;
否则每组VALUES都算一次独立事务，日志刷盘开销翻倍 - 避免动态字符串拼接生成 SQL——易被注入，且长语句编译缓存命中率低；改用参数化批量（如 Python 的
executemany()、Java 的addBatch()） - 如果表有非聚集索引，插入前执行
ALTER INDEX ... DISABLE，插入完再REBUILD，比边插边维护索引快 3–5 倍；但主键/唯一索引不能禁用，否则数据校验失效
为什么禁用约束和索引后还要重建？
禁用非聚集索引只是把 B-Tree 结构标记为 offline，并不删除物理页；但约束（如外键、检查约束）被禁用后，SQL Server 不再校验新数据是否合规。导入完成后，ALTER INDEX ... REBUILD 不仅恢复索引可用性，还会重新排序叶级页、压缩空闲空间；而 WITH CHECK 启用约束会全表扫描验证，这步不能跳过，否则后续查询可能因数据违规返回错误结果。
最容易被忽略的是：所有这些优化都假设你是在离线或低峰期操作。线上表直接 DISABLE 索引或关约束，等于裸奔——并发查询可能读到未验证数据，或因缺失索引导致查询计划彻底劣化。
