Sql 大表上的插入性能非常慢（EF）

我们的一个系统有一个每天接收约20k个插入的表，它目前包含约10m行。我们刚刚推出了一个系统升级，我现在在这个表的插入部分（30-40秒跟踪）上得到了一些令人震惊的低性能。Inserts一次只能插入一行。实体框架正在生成以下SQL：

declare @generated_keys table([ID] uniqueidentifier)

insert [dbo].[Table]([Col1], Col2], etc)

output inserted.[ID] into @generated_keys values (@0, @1, etc)

select t.[ID] from @generated_keys as g join [dbo].[Table] as t on g.[ID] = t.[ID] where @@ROWCOUNT > 0

没有什么不寻常的事情——至少在我看来是这样

该表有12个FK。由于实体表示基于时间的事件，因此聚集索引位于

DateCreated

列上。还有8个非聚集索引，其中包含了各种列。

ID

列是主键，具有唯一的非聚集索引

作为说明，我注意到，由于省略，

ID

列使用的是

newid（）

，而不是

newsequentialid（）

实际执行计划包括以下主要部分：

7x 3%-FK表上的聚集索引搜索

1x 8%-表插入（@生成的\u键）

1x 74%-聚集索引插入，1个实际行，0.09成本

---

我真的很想弄清这件事的真相，但我现在被难倒了。有什么建议吗？

正如您所注意到的，SaveChange为每次插入记录都做一次数据库往返。所以，如果您每天添加20k条记录，则执行20k数据库往返

修改和改进索引几乎没有什么区别，因为真正的问题是数据库往返的次数

要修复性能，必须使用允许执行大容量插入的库

有三个主要的图书馆支持它：

• （推荐并支持所有内容）
• （不支持，使用简单场景）
• （不支持，使用非常简单的场景）

您可以在此处了解有关这三个库的更多信息：

---

免责声明：我是该项目的所有者

您是否尝试放弃ClusteredIndex？它已就位，因为此表上几乎所有select操作都会按日期顺序返回数据。另外，考虑到insert是按日期顺序排列的，在我看来，这列上的聚集索引是有意义的，而不是使用PK列（uniqueidentifier）。运行速度慢的insert是一致的，还是运行速度快的insert数量多，而运行时间长的insert数量多？正如你所说。一个系列/批处理中的第一个查询可能需要一段时间，但随后的运行会很快完成（以我一直期望的速度）。问题似乎不是查询本身，而是连接管理/模型构建。其中哪一个我真的不知道，但是我假设后者，因为模型看起来很复杂。批量插入不是问题，那些20k插入发生在24小时的时间跨度内。保存它们以进行批量插入不是一个选项。