Linq到實體的性能和預生成視圖

Question

我們需要很長時間才能將我們的linq首次運行到EF查詢。我很驚訝地發現在預生成視圖之後沒有區別。我遇到下列要求跑stackoverflow

查看一代不僅有助於對「標準」的查詢（例如，當你調用someObject.RelatedEnd.Load（）或MyContext.SomeSetName（），它不幫助廣告即席查詢使用LINQ或ESQL，原因顯而易見。使用CompiledQuery優化這些。

當他說「由於顯而易見的原因：」我不得不說，「哦，不是明顯對我呢。」如果我沒有理解這個正確地他聲稱Linq SQL查詢不受預生成EF視圖的影響。

我曾想過實體vie ws是實體和表之間的通用映射，與任何特定查詢都沒有關係。這是錯誤的嗎？

我可以看到我們的Linq to Entities查詢的第一次運行中使用了大量的時間，其後的時間顯着更短，所以我假定正在爲相關實體和表生成視圖。如果它不是可以預先生成所有第一次運行時間的EF視圖，那麼它是什麼？

所以我的問題有三個部分：

1. 爲每個查詢生成EF的觀點，還是僅僅涉及表，實體不管查詢製成？

2. 上述聲明是否預生成EF視圖在Linq到EF查詢中沒有區別是正確的？是否必須改用CompileQueries？

3. 上面提到的「顯而易見的原因」是什麼？

注：我甚至不會問，但如果您使用EF，在互聯網上（包括msdn）有很多建議來預生成視圖。這是我見過的唯一的地方，它建議如果你使用Linq到Entities，那麼pregenerating與你的查詢無關。

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以及interactive views for EF6的作者）。然而，我們發現對於EF6中的Code First應用程序來說，實際的瓶頸是構建模型。還有一些其他性能問題 - 有關更多詳細信息，請參閱this blog post。很多這些問題在EF6.0.2中得到修復，因此如果您尚未升級到EF6.0.2，您應該這樣做。我認爲在EF 6.1中還有一些與perf有關的修復程序。

附註： 注意他說LINQ or ESQL而不是Linq to SQL。 ESQL是EF支持的類似於SQL的查詢語言 - 如果您有興趣，可以閱讀更多here。由於EF對LINQ有很好的支持，因此實際上並不是很多情況下您想要使用ESQL而不是Linq to Entities。 Linq to SQL與EF/ESQL/Linq to Entities無關。