為什么LINQ-to-Entities將此查詢放在子選擇中？

Question

我有以下LINQ查詢：

var queryGroups = (from p in db.cl_contact_event
                   select new Groups { inputFileName = p.input_file_name }).Distinct();

運行時轉換為以下內容：

SELECT 
[Distinct1].[C1] AS [C1], 
[Distinct1].[input_file_name] AS [input_file_name]
FROM ( SELECT DISTINCT 
       [Extent1].[input_file_name] AS [input_file_name], 
       1 AS [C1]
       FROM [mel].[cl_contact_event] AS [Extent1]
)  AS [Distinct1]

現在我很確定有一個子選擇的原因是因為我有（）包圍的基本LINQ查詢然后執行.Distinct（）但我不太了解LINQ以確保這一點。 如果確實如此，那么有一種方法可以重構/編碼我的查詢，以便不會發生子選擇嗎？

我知道這似乎我只是在這里挑選，但我只是好奇。

Answer 1

我根本不擔心這種特殊情況。 SQL Server（很可能是任何企業數據庫）無論如何都會優化掉外部的Select語句。 我認為生成此SQL語句的原因是因為這是最通用和可重用的語句。 根據我的經驗，這總是發生在Distinct() 。

Answer 2

在此我懷疑子查詢的實際根本原因是匿名類型構造函數。 因為您沒有選擇已知實體，而是選擇從其他實體值構造的任意對象，所以EF解析器需要確保它可以生成確切的字段集 - 無論是來自單個表，連接表，計算字段，還是其他表達式樹解析器非常善於盡可能地從LINQ查詢中編寫SQL語句，但它並不是無所不知的。 它以系統的方式處理查詢，始終產生正確的結果（從你得到你所要求的意義上），盡管並不總是最佳結果。

至於重寫查詢以消除子選擇，首先關閉：我沒有看到一種明顯的方法來消除匿名類型並產生正確的結果。 更重要的是，我不會打擾 。 像Sybase這樣的現代SQL服務器非常智能 - 通常比開發人員更聰明 - 並且非常擅長從查詢中生成最佳查詢計划。 除此之外，EF喜歡子查詢，因為它們是以自動方式編寫復雜查詢的非常好的方法。 即使您的LINQ查詢沒有出現使用它們，您也經常會找到它們。 試圖從你的查詢中消除它們很快就會變得徒勞無功。