EntityFramework - 查詢執行時間取決於選擇順序？

Question

我注意到了奇怪的行為。 我有商家和訂單表，做兩個選擇一個，其他，選擇非常簡單（從商家選擇*，從訂單中選擇*）。

這是sql profiler跟蹤，當我選擇第一個商家時，然后訂單：

注意，訂單選擇正在服用75秒（這是一個~80.000記錄，在一台非常體面的機器8gb ram，ssd，i7）。

現在，如果我更改順序並選擇第一個訂單，那么商家：

在分析器中，命令查詢執行時間下降到2.5秒，但在應用程序中它與第一種情況大致相同（我猜是因為EF內部嘗試將訂單綁定到商家，因為它們之間存在外鍵）。

所以問題是為什么分析器看到不同的時間以及EF在第二種情況下做了多長時間，可能是某些配置錯誤了？

更新 ：我已經開始使用干凈的EF模型本地化問題，它可以正常工作。 我正在使用EF T4模板生成上下文和實體類，因此它可能已經過時並導致問題，將會知道是否會找到具體的東西 - 我認為這與修復集合有某種關系，所以看起來像SQL分析器有誤導性 - 我猜查詢執行正常，只是等待EF完成閱讀結果或smth（我的意思是EF可能會在讀取結果時做一些有用的事情）。

 using (var myEntities = new myEntities())
        {
            var merchants = myEntities.Merchants.ToList();
            var orders = myEntities.Orders.ToList();
        }

Answer 1

讀取是相同的：只有兩組數據的CPU和持續時間不同。

在第一次迭代中，您將數據從磁盤加載到SQL Server的緩存中。 然后第二個查詢從RAM而不是磁盤讀取4008頁。 商家數據也是如此，但規模較小

注意：表數據和索引是緩存的， 而不是查詢結果。 查詢將每次執行新鮮。 SQL Server保持此緩存是最新的

你說這是可重復的：所以告訴我們代碼。 沒有運行任何清除緩存的DBCC？ SET選項一樣嗎？

Answer 2

持續時間包括執行和獲取時間。 由於在商家已經加載到上下文的情況下，EF必須在Order實例的實現期間建立FK，因此獲取速度較慢。

Answer 3

所以，我發現問題 - 由MS提供的過時的POCO模板。 螞蟻分析器顯示，大部分時間花在管理修復集合上。

使用T4模板：77.4124277秒
使用edmx的默認生成代碼：1.783102秒

正如Vitaliy所提到的 - SQL Profiler持續時間包括執行和獲取時間，我認為這首先讓我感到困惑。