【发布时间】：2016-05-24 09:50:06
【问题描述】：
我们的一个系统有一个每天接收大约 20k 插入的表 - 它目前包含大约 1000 万行。我们刚刚推出了系统升级，现在我在插入此表时遇到了一些令人震惊的缓慢性能（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 列是 PK，具有唯一的非聚集索引。
作为说明，我注意到，由于遗漏，ID 列使用newid() 而不是newsequentialid()。
实际的执行计划包括以下主要部分：
7x 3% - FK 表上的聚集索引查找
1x 8% - 表格插入 (@generated_keys)
1x 74% - 聚集索引插入，1 个实际行，0.09 成本
我真的很想知道这件事的真相，但我现在很难过。有什么建议吗？
【问题讨论】：
-
你试过放弃 ClusteredIndex 吗？
-
它已经到位，因为该表上的几乎所有选择操作都按日期顺序返回数据。此外，鉴于插入是按日期顺序排列的，在我看来，此列上的聚集索引是有意义的，而不是使用 PK 列（唯一标识符）。
-
运行缓慢的插入是否一致，或者您是否有这么多运行速度很快，然后一个需要时间？
-
如你所说。系列/批次中的第一个查询可能需要一段时间，但后续运行会很快完成（以我一直期望的速度）。
-
似乎不是查询本身是问题，而是连接管理/模型构建。其中哪一个我真的不能说，但我假设是后者，因为模型看起来很复杂。
标签： sql sql-server entity-framework sql-server-2012 alwayson