在 SQL Server（C# 客户端）中批量插入大量数据的最快方法是什么

Question

我的 C# 客户端将批量数据插入 SQL Server 2005 数据库时遇到了一些性能瓶颈，我正在寻找加快该过程的方法。

我已经在使用 SqlClient.SqlBulkCopy（它基于 TDS）来加快跨线路的数据传输，这很有帮助，但我仍在寻找更多。

我有一个简单的表格，如下所示：

 CREATE TABLE [BulkData](
 [ContainerId] [int] NOT NULL,
 [BinId] [smallint] NOT NULL,
 [Sequence] [smallint] NOT NULL,
 [ItemId] [int] NOT NULL,
 [Left] [smallint] NOT NULL,
 [Top] [smallint] NOT NULL,
 [Right] [smallint] NOT NULL,
 [Bottom] [smallint] NOT NULL,
 CONSTRAINT [PKBulkData] PRIMARY KEY CLUSTERED 
 (
  [ContainerIdId] ASC,
  [BinId] ASC,
  [Sequence] ASC
))

我在平均大约 300 行的块中插入数据，其中 ContainerId 和 BinId 在每个块中是恒定的，并且序列值是 0-n，并且这些值是根据主键预先排序的。

%Disk time 性能计数器在 100% 上花费了大量时间，因此很明显磁盘 IO 是主要问题，但我得到的速度比原始文件副本低几个数量级。

如果我有帮助：

1. 在我进行插入时删除主键并稍后重新创建它
2. 插入到具有相同模式的临时表中，并定期将它们转移到主表中，以保持发生插入的表的大小较小
3. 还要别的吗？

——根据我得到的答复，让我澄清一下：

Portman：我正在使用聚集索引，因为当数据全部导入后，我需要按顺序依次访问数据。 导入数据时，我并不特别需要索引。 在进行插入时使用非聚集 PK 索引而不是完全删除约束以进行导入有什么好处？

Chopeen：数据是在许多其他机器上远程生成的（我的 SQL 服务器目前只能处理大约 10 个，但我希望能够添加更多）。 在本地机器上运行整个过程是不切实际的，因为它必须处理 50 倍的输入数据才能生成输出。

Jason：在导入过程中，我没有对表进行任何并发查询，我会尝试删除主键，看看是否有帮助。

Answer 1

以下是在 SQL Server 中禁用/启用索引的方法：

--Disable Index ALTER INDEX [IX_Users_UserID] SalesDB.Users DISABLE
GO
--Enable Index ALTER INDEX [IX_Users_UserID] SalesDB.Users REBUILD

以下是一些可帮助您找到解决方案的资源：

一些批量加载速度比较

使用 SqlBulkCopy 将数据从客户端快速加载到 SQL Server

优化批量复制性能

一定要研究 NOCHECK 和 TABLOCK 选项：

表提示 (Transact-SQL)

插入 (Transact-SQL)

Answer 2

您已经在使用SqlBulkCopy ，这是一个好的开始。

但是，仅仅使用 SqlBulkCopy 类并不一定意味着 SQL 会执行大容量复制。 特别是，SQL Server 必须满足一些要求才能执行有效的批量插入。

进一步阅读：

• 批量导入中最小日志记录的先决条件
• 优化批量导入性能

出于好奇，为什么你的索引是这样设置的？ 看起来 ContainerId/BinId/Sequence更适合作为非聚集索引。 您希望这个索引聚集在一起有什么特别的原因吗？

Answer 3

我的猜测是，如果您将该索引更改为 nonclustered，您会看到显着的改进。 这使您有两个选择：

1. 将索引更改为非聚集索引，并将其保留为堆表，没有聚集索引
2. 将索引更改为非聚集索引，然后添加代理键（如“id”）并使其成为标识、主键和聚集索引

任何一个都可以加快您的插入速度，而不会显着减慢您的读取速度。

这样想——现在，您告诉 SQL 进行批量插入，但随后您要求 SQL 对您添加任何内容的每个表重新排序。 使用非聚集索引，您将按照它们进入的任何顺序添加记录，然后构建一个单独的索引来指示它们所需的顺序。

Answer 4

您是否尝试过使用交易？

根据您的描述，让服务器将 100% 的时间提交到磁盘，您似乎正在以原子 SQL 语句发送每一行数据，从而迫使服务器每行提交（写入磁盘）。

如果您改用事务，则服务器只会在事务结束时提交一次。

如需进一步帮助：您使用什么方法将数据插入服务器？ 使用 DataAdapter 更新 DataTable，还是使用字符串执行每个句子？

Answer 5

我不是一个真正聪明的人，我对 SqlClient.SqlBulkCopy 方法没有太多经验，但这是我的 2 美分，它的价值。 我希望它可以帮助您和其他人（或至少使人们指出我的无知；）。

除非您的数据库数据文件 (mdf) 与事务日志文件 (ldf) 位于单独的物理磁盘上，否则您将永远无法匹配原始文件复制速度。 此外，任何聚集索引也需要位于单独的物理磁盘上，以便进行更公平的比较。

您的原始副本没有记录或维护选择字段（列）的排序顺序以用于索引目的。

我同意 Portman 关于创建非聚集标识种子并将现有的非聚集索引更改为聚集索引的观点。

至于您在客户端上使用的构造...（数据适配器、数据集、数据表等）。 如果服务器上的磁盘 io 为 100%，我认为最好不要花时间分析客户端构造，因为它们似乎比服务器当前可以处理的速度更快。

如果您关注 Portman 关于最小日志记录的链接，我认为围绕事务中的批量副本不会有很大帮助，但我在我的生活中犯过很多次错误；）

这不一定对您现在有帮助，但如果您弄清楚当前的问题，下一条评论可能有助于解决下一个瓶颈（网络吞吐量） - 特别是如果它通过 Internet...

Chopeen 也问了一个有趣的问题。 您如何确定使用 300 个记录计数块来插入？ SQL Server 有一个默认的数据包大小（我相信它是 4096 字节），对我来说，推导出记录的大小并确保您有效地利用客户端和服务器之间传输的数据包是有意义的。 （注意，您可以在客户端代码上更改数据包大小，而不是服务器选项，这显然会针对所有服务器通信更改它 - 可能不是一个好主意。）例如，如果您的记录大小导致 300 个记录批次需要 4500字节，您将发送 2 个数据包，而第二个数据包大部分被浪费。 如果批量记录计数是任意分配的，那么做一些快速简单的数学运算可能是有意义的。

据我所知（并记住数据类型大小），每条记录恰好有 20 个字节（如果 int=4 字节和 smallint=2 字节）。 如果您使用 300 个记录计数批次，那么您正在尝试发送 300 x 20 = 6,000 字节（另外我猜测连接会产生一些开销等）。 以 200 个记录计数批次（200 x 20 = 4,000 + 开销空间）= 1 个数据包发送这些可能会更有效。 再说一次，您的瓶颈似乎仍然是服务器的磁盘 io。

我意识到您正在将原始数据传输与具有相同硬件/配置的 SqlBulkCopy 进行比较，但如果挑战是我的，我也会去这里：

这篇文章可能不再对您有帮助，因为它已经很老了，但是我接下来会问您磁盘的 RAID 配置是什么以及您使用的磁盘速度是多少？ 尝试将日志文件放在数据文件上使用 RAID 10 和 RAID 5（理想情况下为 1）的驱动器上。 这可以帮助减少大量主轴移动到磁盘上的不同扇区，并导致更多时间读/写，而不是非生产性的“移动”状态。 如果您已经将数据和日志文件分开，您的索引是否与数据文件位于不同的物理磁盘驱动器上（您只能使用聚集索引来执行此操作）。 这不仅允许在插入数据的同时更新日志信息，而且允许同时进行索引插入（以及任何代价高昂的索引页操作）。

Answer 6

BCP - 设置起来很痛苦，但它从 DB 诞生之初就已经存在，而且速度非常快。

除非您按该顺序插入数据，否则 3 部分索引确实会减慢速度。 稍后应用它也确实会减慢速度，但将是第二步。

Sql中的复合键总是很慢，键越大越慢。

Answer 7

我认为这听起来可以使用SSIS 包来完成。 它们类似于 SQL 2000 的 DTS 包。 我已经使用它们成功地转换了纯文本 CSV 文件、现有 SQL 表，甚至是跨多个工作表的 6 位行的 XLS 文件。 您可以使用 C# 将数据转换为可导入的格式（CSV、XLS 等），然后让您的 SQL 服务器运行计划的 SSIS 作业来导入数据。

创建 SSIS 包非常容易，SQL Server 的企业管理器工具中内置了一个向导（我认为标记为“导入数据”），在向导结束时，您可以选择将其保存为 SSIS 包。 Technet上还有更多信息。

Answer 8

还在面对这个问题吗？ 也试试这个。

• 检查数据库配置（内存和处理器）。
• 对于大容量数据，我建议至少 16GB 的内存和16 的处理器

Answer 9

是的，你的想法会有所帮助。
如果在加载时没有发生读取，请使用选项 1。
如果在处理过程中查询目标表，请使用选项 2。

@安德鲁
问题。 您插入 300 块。您插入的总量是多少？ SQL 服务器应该能够非常快速地处理 300 个普通的旧插入。