LINQ to Entities 4.0 查询是否默认编译？答案

【问题标题】：Are LINQ to Entites 4.0 Queries Compiled By Default?LINQ to Entities 4.0 查询是否默认编译？
【发布时间】：2010-06-26 10:13:29
【问题描述】：

我最近才开始每天使用 LINQ。我已经阅读了很多关于 L2E 查询应该被编译以提高性能的文章：

CompiledQuery.Compile(query);

使用 LINQ-To-Entities 4.0 我在未编译的情况下运行了 10 次查询，然后编译并在几秒钟内产生了以下结果：

// Sample Query
from u in ctx.Users orderby u.Id, u.Username select u

Uncompiled  Compiled
---------------------
0.295       0.2946174
0.024       0.0220462
0.008       0.0060126
0.013       0.0210441
0.007       0.010021
0.011       0.010021
0.008       0.0060126
0.009       0.0070147
0.008       0.0060126

如您所见，与我的小测试相比，时间并没有太大差异。第一次调用的时间较慢，然后都加快（暗示编译/缓存）。任何人都可以对此提供见解吗？

【问题讨论】：

前段时间研究过这个问题，但是（这绝对不是确定的）答案是否定的。如果我能找到明确的答案，我会在这里给出，但如果没有人这样做，则假设不会。
那么第一次评估查询时发生了什么？

标签： c# linq linq-to-entities

【解决方案1】：

据我所知，嵌入参数的硬编码 SQL 查询与使用命名参数的 SQL 查询具有大致相同的好处：系统可以识别它们都是相同的并使用相同的查询计划。

例如，如果您要简单地内联上面的表达式，那么如果您总是传入相同的 ctx.Users 对象，它可能会像编译它一样工作。但是，如果您有多个相同类型的用户存储库并计划在所有用户存储库上使用 order by，那么最好编译一次查询并使用参数来访问它。

在研究这一点时，我查看了在 IL 中如何形成 LINQ 查询：每次调用时，都会为 LINQ 查询中的每个子句创建一个新的 Func<> 委托。仅出于这个原因，我认为就内存抖动而言，编译查询对您的系统来说会更好。

【讨论】：

是的，我意识到 SQL 服务器显然正在对查询进行一些缓存，因为未编译的版本在第一次运行查询时存在相同的性能问题。今天在我的家用机器上进行了更多测试后，我能够看到编译查询在我的环境中平均快 0.001 秒。虽然不多，但很有趣。

【解决方案2】：

您可能没有处理上下文。查询缓存在上下文中，但编译它们允许您跨多个上下文使用它们。很难确定，因为您实际上并没有显示完整的代码。

【讨论】：

不，它被包装在using 语句中，该语句在单击按钮时调用的方法内（我没有代码，但我知道我正在处理的事实它）。
如果你想得到答案，你将不得不发布代码。