Linq对实体的表现和前期观点 [英] Linq to Entities performance and pregenerating views

问题描述

我们花了很长时间第一次运行我们的linq到EF查询。在预先发现观点之后，我感到惊讶的是没有任何区别。我在 stackoverflow 上遇到以下声明：

查看生成仅对标准查询有帮助（例如，当您调用someObject.RelatedEnd.Load（）或MyContext.SomeSetName（）时，这对于使用LINQ或ESQL的临时查询无效，原因很明显使用CompiledQuery来优化这些。

当他说显而易见的原因我不得不说：对我来说不是很明显但是，如果我明白这一点，他声称Linq对SQL查询不受预生成EF视图的影响。

我以为实体视图是实体和表之间的通用映射，并且与任何具体的查询无关，这是否错误？

我可以看到在我们的Linq to Entities查询的第一次运行中使用了大量的时间，此后大幅减少，所以我认为正在为有关实体和ta创造意见统计局。如果不是可以预先考虑所有首次运行时间的EF视图，那么它是什么？

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

1. 是否为每个查询生成了EF视图，或者只是将表与实体相关联，而不考虑所做的查询？




2. 上述声明认为，EFq的预生成EF视图与EF查询的区别是否正确？有人需要使用CompileQueries吗？



3. 以上提到的明显原因是什么？

：我甚至不会问，但是如果你使用EF，互联网上有很多建议（包括msdn）来预览视图。这是我看到的唯一的地方，建议如果您使用Linq到实体，那么预生成与您的查询无关。

解决方案

我不认为你发现的答案是正确的。您可以将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的预生成视图（我将其称为 EF6的交互式视图）。然而，我们发现，对于EF6中的Code First应用程序，实际的瓶颈是建立模型。还有一些其他perf问题，请参阅这篇博客文章了解更多细节。在EF6.0.2中修复了很多这些问题，所以如果你还没有升级到EF6.0.2，你应该。我认为EF 6.1中有更多的perf相关修复。

旁注：
注意他说 LINQ或ESQL 而不是 Linq to SQL 。 ESQL是EF支持的类似SQL的查询语言 - 如果您有兴趣，可以阅读更多这里。由于EF对LINQ有很好的支持，因此您不希望使用ESQL而不是Linq to Entities来实现很多场景。 Linq to SQL与EF / ESQL / Linq to Entities无关。

We are taking a long time on first runs of our linq to EF queries. I was surprised to see no difference after pre-generating views. I ran across the following claim on stackoverflow

View generation only helps for "standard" queries (e.g., when you call someObject.RelatedEnd.Load() or MyContext.SomeSetName(). It doesn't help for ad hoc queries with LINQ or ESQL, for obvious reasons. Use CompiledQuery to optimize those.

When he says "for obvious reasons" I have to say, "Well,not obvious to me yet". If I understand this correctly he is claiming Linq to SQL queries are not affected by pregenerating EF views.

I had thought entity views were generic mappings between entities and tables, and bore no relation to any specific query. Is this mistaken?

I can see huge amounts of time being used in the first run of our Linq to Entities queries, with dramatically smaller times thereafter, so I assumed views were being generated for the relevant entities and tables. If it isn't an EF view that can be pregenerated taking all that first run time, then what is it?

So my question has three parts:

1. Are EF views generated for each query, or do they just relate tables to entities regardless of the queries made?

2. Is the above claim that pregenerating EF views makes no difference in Linq to EF queries correct? Does one have to use CompileQueries instead?

3. What are the "obvious reasons" referred to above?

Note: I wouldn't even ask but there are quite a few recommendations on the internet (including msdn) to pregenerate views if you are using EF. This is the only place I have seen it suggested that if you use Linq to Entities then pregenerating is irrelevant to your queries.

解决方案

I don't think the answer you found is correct. You can think of EF views as of a way of abstracting the database so that EF can do its stuff without knowing anything about the actual database. Therefore EF requires views for any query or modification operation that goes through the EF query/update pipeline. In fact, any/all EF queries (be it Linq queries or ESQL queries) are built by composing on base queries which are actually the views.

To answer your questions:

• Views are generated only once typically on the first query
• compiled queries and views are orthogonal - I explained views above, compiled queries are about caching the generated SQL for a query to avoid compiling the query again. This helps because typically a set of queries used in an app is limited so the generated SQL can be cached (note that if you pass parameters to the query this does not affect the generated SQL since it will be parameterized as well). Starting from EF5 the caching happens automatically (http://blogs.msdn.com/b/efdesign/archive/2011/06/30/auto-compiled-linq-queries-entity-framework-june-2011-ctp.aspx).

In EF6 there have been a number of improvements to view generation. I would say that in the vast majority of cases you shouldn't have to use pre-generated views with EF6 at all (and I say this as the author of the T4 templates for generating views for EF5 and EF6 and also interactive views for EF6). However we found that for Code First apps in EF6 the actual bottleneck was building the model. There were a few other perf issues as well - see this blog post for more details. A lot of these issues were fixed in EF6.0.2 so if you have not upgraded to EF6.0.2 you should. I think there is a few more perf related fixes coming in EF 6.1.

Side note: Note he said LINQ or ESQL and not Linq to SQL. ESQL is a SQL-like query language supported by EF - if you are interested you can read more here. Since EF has a good support of LINQ there is not really a lot of scenarios where you would want to use ESQL rather than Linq to Entities. Linq to SQL is unrelated to EF/ESQL/Linq to Entities.

这篇关于Linq对实体的表现和前期观点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！