Linq to Entities性能和预生成视图

Question

我们在首次运行linq到EF查询时花了很长时间。在预先生成视图后，我感到惊讶的是看到没有区别。我在stackoverflow

上遇到了以下声明

  

视图生成仅对“标准”查询有帮助（例如，当您调用someObject.RelatedEnd.Load（）或MyContext.SomeSetName（）时。由于显而易见的原因，它对使用LINQ或ESQL的即席查询没有帮助。使用CompiledQuery优化这些。

当他说“出于显而易见的原因”时，我不得不说，“嗯，对我来说还不明显”。如果我理解正确，他声称Linq to SQL查询不受预生成EF视图的影响。

我认为实体视图是实体和表之间的通用映射，并且与任何特定查询无关。这是错的吗？

我可以看到在我们的Linq to Entities查询的第一次运行中使用了大量的时间，之后显着缩短了时间，因此我假设正在为相关实体和表生成视图。如果不是EF视图可以预先生成所有第一次运行时间，那么它是什么？

所以我的问题有三个部分：

1. 是为每个查询生成EF视图，还是只是将表与实体关联起来而不管查询是什么？

2. 上述声明预生成EF视图在Linq到EF查询中没有区别吗？是否必须使用CompileQueries？

3. 上面提到的“显而易见的原因”是什么？

注意：我甚至不会问，但如果您使用EF，互联网（包括msdn）上有很多建议可以预生成视图。这是我见过的唯一一个建议，如果你使用Linq to Entities，那么预生成与你的查询无关。

Answer 1

我认为您找到的答案是正确的。您可以将EF视图视为抽象数据库的一种方式，以便EF可以在不了解实际数据库的情况下完成其工作。因此，EF需要查看通过EF查询/更新管道的任何查询或修改操作的视图。实际上，任何/所有EF查询（无论是Linq查询还是ESQL查询）都是通过在基本查询上进行构建来构建的，这些查询实际上是视图。

回答你的问题：

• 通常只在第一个查询
上生成一次视图
• 编译的查询和视图是正交的 - 我解释了上面的视图，编译的查询是关于为查询缓存生成的SQL以避免再次编译查询。这有帮助，因为通常在应用程序中使用的一组查询是有限的，因此可以缓存生成的SQL（请注意，如果将参数传递给查询，这不会影响生成的SQL，因为它也将被参数化）。从EF5开始，缓存自动发生（http://blogs.msdn.com/b/efdesign/archive/2011/06/30/auto-compiled-linq-queries-entity-framework-june-2011-ctp.aspx）。

在EF6中，对视图生成进行了许多改进。我想说在绝大多数情况下你根本不应该使用EF6的预生成视图（我说这是EF5和EF6 T4 templates for generating views的作者以及{{3} }）。但是我们发现，对于EF6中的Code First应用程序，实际的瓶颈是构建模型。还有一些其他性能问题 - 有关详细信息，请参阅interactive views for EF6。 EF6.0.2中修复了很多这些问题，所以如果你没有升级到EF6.0.2，你应该这样做。我认为EF 6.1中还有一些与性能相关的修复。

旁注： 请注意，他说LINQ or ESQL而不是Linq to SQL。 ESQL是EF支持的类似SQL的查询语言 - 如果您有兴趣，可以阅读更多this blog post。由于EF对LINQ有很好的支持，因此实际上并没有很多场景需要使用ESQL而不是Linq to Entities。 Linq to SQL与EF / ESQL / Linq to Entities无关。