Sql 快速插入；使用关系数据进行批量复制

我有大量不断传入的数据（大约每分钟10000个，并且还在增长），我希望尽可能高效地将这些数据插入数据库。目前我正在使用准备好的insert语句，但我正在考虑使用SqlBulkCopy类以更大的块导入数据

问题是我没有插入到单个表中——数据项的元素被插入到多个表中，它们的标识列被用作同时插入的其他行中的外键。我知道大容量复制并不意味着允许像这样更复杂的插入，但我想知道是否值得将我的标识列（在本例中为bigint）交换为uniqueidentifier列。这将允许我为每个表执行两个大容量复制，并且因为我可以在插入之前确定ID，所以我不需要检查SCOPE_IDENTITY之类的任何东西，因为它阻止我使用大容量复制

这听起来是一个可行的解决方案，还是我可能会面临其他潜在问题？或者，是否有其他方法可以快速插入数据，但保留对bigint标识列的使用

---

谢谢。

听起来您计划将“SQL分配[bigint identity（）column]代理项键”与“数据准备例程分配GUID代理项键”方法交换。换句话说，密钥不会在SQL内部分配，而是从SQL外部分配。考虑到您的容量，如果数据生成过程可以分配代理密钥，我肯定会这样做

---

接下来的问题是，您必须使用guid，还是数据生成过程能够生成自动递增的整数？创建这样一个工作始终如一且无误的过程是很困难的（您为SQL Server支付$$$的一个原因），但在数据库中为更小、更易于识别的键进行权衡可能是值得的。

uniqueidentifier可能会让事情变得更糟：页面拆分和更宽。看

如果您的负载是/可以批处理的，一个选项是：

• 您可以加载一个暂存表
• 作为存储过程一次性加载实际表
• 在暂存表中为每个批次使用唯一标识符

---

我们处理每秒约50k行的峰值（并以这种方式增加）。实际上，我们使用一个单独的暂存数据库来避免双重事务日志写入）

“创建这样一个工作一致且无误的流程是很困难的…”没错，但如果您在数据库之外的单个非共享应用程序中进行此操作，则会容易得多。没有争用，没有竞争条件，没有事务。我尝试了GUID，获得了10倍的性能（大约每秒10000次插入）：）我正在使用C#中生成的顺序GUID（aka.COMB）进行试验，我认为这应该可以解决链接中的聚集索引问题。乍一看，我非常喜欢您的staging table想法，我认为这意味着使用GUIDs PKs存储行，然后将它们传输到具有IDENTITY PKs的表中。然而，由于我需要获取标识列，这是否仍然需要进行大量插入？也许我误解了。@bargaust：我们使用GUID来标识单个批（一些来自SQL BulkCopy，另一些由一些风险引擎生成）。然后我们使用bigint集群键刷新主表。GUID不是聚集键，只是跟踪批量数据以便刷新到主表的一种方法。GUID仍然是16字节宽，无论是否连续，这总计超过数十亿行。