來自實體框架的生成T-SQL的性能

儘管我的DBA強烈反對，但我最近使用了Entity Framework作爲項目。所以有一天，他來到我的辦公室抱怨生成的T-SQL到達他的數據庫。來自實體框架的生成T-SQL的性能

舉例來說，當我想根據id選擇一個產品，我寫的是這樣的：

context.Products.FirstOrDefault(p=>p.Id==id);

它轉換爲

SELECT ... FROM (SELECT TOP 1 ... FROM PRODUCTS WHERE [email protected])

於是，他喊的是：「爲什麼上你會寫一個SELECT * FROM（SELECT TOP 1）「

所以我把我的代碼改成了

context.Products.Where(p=>p.Id==id).ToList().FirstOrDefault()

並且這產生更清潔的T-SQL：

SELECT ... FROM PRODUCTS WHERE [email protected]

內查詢和TOP 1 dissappeared。足夠的混亂，我的問題是這樣的：第一個查詢是否真的把SQL Server的開銷？比第二種方法更難解析嗎？ Id列上有一個聚集索引。我想一個很好的答案，所以我可以擦在臉上（或礦）

感謝，
Themos

來源

2012-06-13 Themos Piperakis

你可以讓他發送給你兩個查詢的執行計劃嗎？那會讓你頭腦發熱。不過，我認爲作爲DBA，識別TSQL查詢中的瓶頸非常重要，並幫助開發人員瞭解如何提高代碼效率。摩擦彼此面臨的是一場不會真正惠及任何人的自我之戰。使用ORM工具有時會導致生成錯誤的SQL。但嚴重寫TSQL代碼具有相同的效果。聽起來像DBA非常注重他的方式，你會爭取一個很難改變的個人觀點。 – Namphibian

你試過手動運行查詢和比較的執行計劃？

這裏最大的問題不在於SQL不完全符合您的DBA標準（雖然我確信查詢引擎會優化額外的選擇）。第二個查詢實際上返回Products表中的全部內容，然後您可以在內存中分析這些內容，這絕對是一個應該由數據庫而不是應用程序層執行的任務。

總之，他是一個學生，讓它保持原樣。

來源

2012-06-13 11:10:23 Dave

篩選仍在數據庫中運行，請參閱生成的（發佈的）SQL。 –

@HansKesting - 對不起，到目前爲止，必須有這些日子之一... – Dave

@HansKesting ID上的過濾器被翻譯成SQL。 'FirstOrDefault（）'在原始查詢中被翻譯成SQL，但不是在修改後的查詢中，而是在物化結果集上工作。它仍然返回相同的結果，但在內存中而不是在數據庫中處理。 – Suncat2000

來自實體框架的生成T-SQL的性能

回答

相關問題