实体框架生成的 SQL - SELECT TOP (X) 比 SELECT 多花费 500% 的时间

Question

我正在开发一个使用实体框架的 MVC 网站。我是一名前 ADO.Net 表单人员，所以这对我来说有点新鲜。我的 EDM 当前由一个抽象的“产品”实体组成，该实体有 5 个继承自它的不同“类型”实体。 “产品”实体映射到 7 或 8 个表，并具有大约 50 个属性，从“产品”继承的每个“类型”都有大约 5 到 20 个扩展“产品”的额外属性。我注意到，当我在 IQueryable 上使用 .Take 扩展方法将数据返回到 Telerik 网格时，返回数据所花费的时间明显比我只是使用 .ToList 贪婪地将整个集合返回到内存时要长。

当我运行 SQL Profiler 来查看究竟发生了什么时，我发现了以下内容。

exec sp_executesql N'SELECT TOP (20)
[Project12].[C1] AS [C1], 
[Project12].[C2] AS [C2], 
[Project12].[C3] AS [C3], 
etc ... 508 SQL lines follow, too much to paste here unfortunately.

执行需要 500 毫秒。然而，以下内容：

exec sp_executesql N'SELECT
[Project12].[C1] AS [C1], 
[Project12].[C2] AS [C2], 
[Project12].[C3] AS [C3], 
etc ... 

执行大约需要 80 毫秒。

因此，根据上述逻辑判断，我应该放弃延迟执行，并且每次用户更改页面时......将整个数据集放入内存（500 行左右）。有谁对发生了什么以及为什么 SQL Server 2005 会这样表现有任何建议吗？

编辑

我已将完整的SQL放在http://pastebin.com/rAGGSScA .难道 SQL 正在缓存“完整”选择，而不缓存“TOP (20)”结果？

SELECT 的客户端统计信息

SELECT TOP (20) 的客户端统计信息 >

Answer 1

在“后面的 508 条 SQL 行”中的某个位置将有一个 ORDER BY 子句。通过强制对查询进行“TOP (N)”评估，您将强制服务器更早地评估此 order by 子句，并在 之前计算所有 结果（包括它们的顺序）任何都可以显示。您可能最终会得到一个完全不同的执行计划，甚至可能使索引无效（或与不太理想的索引匹配）。如果没有“TOP (n)”子句，服务器一旦知道将使用记录就可以开始显示结果。

Answer 2

如果它们都有 ORDER BY ，那么我的猜测是，慢速计划使用的是不同的计划，该计划通常效率较低，但以所需的排序顺序输出行，而快速计划使用不同的计划它以未排序的顺序输出行，并具有显式的 SORT 步骤。

可能的情况是，当使用较慢的计划时，SQL Server 需要处理超过 20 行才能获得输出的TOP 20（因为许​​多行被连接或 where 子句条件消除）并且它没有正确估计这个因素，导致它错误地认为慢速计划比快速计划便宜。