c# - SqlBulkCopy 性能

Question

我正在努力提高批量加载的性能；每天 100 条数百万条记录。

我将其移至使用 IDatareader 界面来代替数据表，并且确实获得了显着的性能提升(每分钟增加 500,000 条记录)。当前设置是:

• 一个自定义缓存读取器来解析分隔文件。
• 将流读取器包装在缓冲流中。
• 一个自定义对象读取器类，它枚举对象并实现 IDatareader 接口(interface)。
• 然后SqlBulkCopy写入服务器

大部分性能瓶颈直接在 SqlBulkCopy.WriteToServer 中。如果我对进程进行单元测试，但不包括 WriteToServer，则进程将在大约 1 分钟内返回。 WriteToServer 需要额外 15 分钟以上的时间。对于单元测试，它在我的本地机器上，因此数据库位于同一驱动器上，因此它不必通过网络复制数据。

我正在使用堆表(无索引；集群或非集群；我尝试过各种批处理大小，性能没有重大差异)。

需要减少加载时间，所以我希望有人现在可以想办法从这次出现的事件中挤出更多的血。

Answer 1

为什么不直接使用SSIS呢？

无论如何，如果您从解析到 IDataReader 进行了处理，那么您已经走在了正确的道路上。要优化 SqlBulkCopy 本身，您需要将注意力转向 SQL Server。关键是最少记录操作。您必须阅读这些 MSDN 文章:

• Prerequisites for Minimal Logging in Bulk Import .
• Optimizing Bulk Import Performance .

如果您的目标是 B 树(即聚簇索引表)，不幸的是，无法声明高性能批量插入的最重要原则之一，即排序输入行集。就这么简单，ADO.Net SqlClient 没有 SSPROP_FASTLOADOPTIONS -> ORDER(Column) 的等价物(OleDb)。由于引擎不知道数据已经排序，因此它会在计划中添加一个排序运算符，这不是那么糟糕，除非它溢出。为避免溢出，请使用小批量 (~10k)。看我的原话:这些都是options and clicks to set in SSIS而不是挖掘 OleDB MSDN 规范...

如果您的数据流一开始是未排序的，或者目标是堆，那么我上面的观点是无效的。

但是，实现最低限度的日志记录仍然是获得良好性能的必要条件。