SqlBulkCopy是C#批量导入SQL Server最快方式，但需用DataTable、显式列映射、合理设置批大小与超时，并注意类型对齐、空值处理及约束校验。
SqlBulkCopy 是 C# 中批量导入数据到 SQL Server 的最快方式，但它不是万能的“一键导入”工具——用错场景、忽略约束或类型不匹配，反而比逐条 INSERT 还慢，甚至直接抛出难以定位的 InvalidOperationException 或截断错误。
SqlBulkCopy 前必须准备 DataTable（不能直接传 List<T>）
SqlBulkCopy 不接受 List<MyEntity> 或 IEnumerable<T>，必须是结构明确的 DataTable。手动构建时注意列顺序、空值和类型对齐——SQL Server 的 datetime2 列若传入 DateTime.MinValue 会报错，需转为 null 或合法最小值 new DateTime(1,1,1)。
实操建议：
- 用
DataTable.Clone()复制表结构，再用Rows.Add()填充，避免列名拼写错误 - 对可空字段，确保
DataRow对应列为DBNull.Value，而非null（C# null 与 DB null 不等价） - 避免在循环中反复调用
DataTable.Rows.Add(object[])—— 先收集好所有行，一次性AddRange（需自行扩展）或用Load(DataReader)
ColumnMappings 必须显式设置（尤其当列名不一致时）
如果 DataTable 列名与目标表字段名不同（比如 UserId vs user_id），不设 ColumnMappings 会导致静默跳过或顺序错位——SqlBulkCopy 默认按列索引位置映射，不是按名称。
常见错误现象：数据插进去了，但几列值全乱了，或者部分字段始终为 NULL。
实操建议：
- 始终显式添加映射：
bulk.ColumnMappings.Add("UserId", "user_id") - 用
Ordinal映射更稳定（bulk.ColumnMappings.Add(0, 0)），适合列顺序固定且已知的场景 - 别依赖
DataTable的TableName或DataSet关系——SqlBulkCopy 完全不读这些元信息
事务、超时与批大小要按实际负载调整
默认 BatchSize = 0 表示“整个 DataTable 为一批”，内存压力大且失败后全部回滚；Timeout 默认 30 秒，在百万级导入时大概率超时。
性能影响明显：
-
BatchSize = 10000通常平衡速度与内存占用；超过 50000 可能触发 tempdb 增长或锁升级 -
DestinationTableName必须是完整三段式名（如[dbo].[Orders]），带 schema 才支持分区表或同义词 - 开启
SqlBulkCopyOptions.TableLock可提升速度，但会阻塞其他查询——生产环境慎用，优先考虑KeepIdentity或FireTriggers是否真需要
遇到 “String or binary data would be truncated” 怎么快速定位？
这不是 SqlBulkCopy 自身报的错，而是 SQL Server 在插入时检测到字符串超长触发的异常。由于批量操作不返回具体哪一行哪一列出问题，排查极难。
解决思路：
- 先用
DataTable.AsEnumerable().Max(r => r.FieldCount("Name"))检查各列最大长度是否超过目标字段定义 - 临时把目标列改为
nvarchar(max)测试，确认是截断问题后再收缩 - 不要依赖
SqlBulkCopy.WriteToServer()的异常堆栈——它只告诉你“第 X 行失败”，但不会说 X 是 DataTable 行号还是数据库行号；加try/catch并记录DataRow.RowError无效，BulkCopy 不填充该属性
真正麻烦的是外键约束、唯一索引冲突和触发器逻辑——SqlBulkCopy 绕过触发器（除非显式启用），但约束检查照常执行。如果目标表有复杂业务规则，批量前最好先做内存校验，而不是指望数据库报错再重试。
