實體框架的SQL查詢性能

我試圖讓實體框架性能的句柄，特別是圍繞動態SQL就會產生。以下面的語句爲例：實體框架的SQL查詢性能

var orders = db.Orders.Include(o => o.OrderItem).Include(o => o.Customer);

這將返回所有訂單附加的訂單項目和訂購它的用戶的客戶詳細信息。

這將大致轉換到SQL，如下面：

Select * 
from Order o 
inner join OrderItem oi on o.OrderId = oi.OrderId 
inner join Customer c on o.CustomerId = c.CustomerId

現在（在SQL Server的情況下），這個計劃可以被緩存和這個例子很簡單，但作爲查詢變得越來越動態和複雜的參數，條件，變量等等，數據庫性能會成爲EF的問題，並且將使用編譯或其他對象的存儲過程，而不是讓EF生成動態SQL變得更高效？

或者我們可以假設EF是高度優化的，除了複雜場景中數據庫級別需要SPROCS，視圖，函數等的場景外，我們可以依靠EF在其SQL查詢中儘可能高效？ EF的SQL代碼

來源

2011-11-23 Fitzroy79

歡迎StackOverflow上：如果您發佈的代碼，XML或數據樣本，** **請在高亮文本編輯器的線和編輯器工具欄上單擊「代碼示例」按鈕（'{}'）很好地格式和語法突出顯示它！ –

只是兩點意見：首先，EF已經被廣泛的測試，和它背後的人真正瞭解SQL Server和如何構建高效的查詢，所以對於絕大多數的EF查詢，會隨着你會寫什麼好你自己 - 或更好。其次，EF使用參數化查詢，所以如果相同的查詢再次出現，只需使用不同的參數值，就可以重新使用緩存的執行計劃 –

質量是應該擔心你最少的事情。 EF本身足夠慢。 SQL Server（尤其是最新版本）可以很好地進行查詢優化，所以你通常不會比一些手寫的SP慢。但總的來說，在使用EF的情況下，與使用ADO.NET + DataTables的純請求相比，程序的響應速度會更慢，響應也更少。然而，這並不意味着EF是壞事，但你必須仔細考慮在哪裏使用它。

來源

2011-11-23 12:31:57

實體框架的SQL查詢性能

回答

相關問題