這不是「哪個是最快的ORM」的問題，也不是「如何使用ORM編寫好的代碼」的問題。這是另一面：代碼已經寫好，它已經上線了，數千用戶正在使用這個應用程序，但是有一個可感知的整體性能問題。一個SQL事件探查器跟蹤只能運行很短的時間：5分鐘可以得到幾十萬個結果。跟蹤ORM性能
問題很簡單：使用SQL事件探查器來縮小大量慢速查詢（持續時間大於給定的時間量），有什麼技術和解決方案將這些SQL查詢追溯回有問題的組件？一個相關的問題是，如果某個特定區域很慢，我們如何識別該區域正在執行的SQL，以便可以在SQL Profiler中對其進行適當的過濾？
對此的背景是我們有一個相當大的應用程序，具有相當複雜的表結構，目前基於數據訪問通過存儲過程。如果出現SQL性能問題，通常會拖出SQL事件探查器，查看是否有緩慢的事件（按持續時間過濾），或者被投訴的區域是否緩慢（按存儲過程過濾），並調整存儲過程（或架構 - 通過索引）。
現在推動我們的代碼從大多數存儲解決方案轉移到大多數ORM解決方案，但是反對這一舉措的重大推動是性能問題（如果它們出現的話）可以追溯到有問題的代碼。我已經閱讀了一遍，似乎更多的時候，它可能涉及我們需要在服務器上安裝的第三方工具（ORM跟蹤實用程序，如NHProf或.NET跟蹤utils，如dottrace）。現在是否可以在現場環境中安裝其他工具是另一個問題，因此如果這樣的事情可以在沒有其他工具的情況下執行，那麼這可能是一種獎勵。
我最感興趣的是SQL Server 2008的解決方案，但對於任何RDBMS來說，它可能是通用的。就ORM技術而言，在這方面我沒有特別的關注，因爲目前沒有任何東西在使用，所以有興趣瞭解技術如何不同（或共同），如何使用nHibernate，流利的nhibernate和實體框架。其他ORM歡迎，但如果他們提供的東西:-)
我已經通過How to find and fix performance problems (...)通讀，我認爲問題只是在那裏說「隔離」的部分。一個很容易重現的問題只有在一個實時系統上將很難分離。我在第2段中引用的數字是數字，我們可以從配置文件中獲得的音量類型以及...
如果您有實際的ORM跟蹤經驗，那麼更好:-)
更新，2016-10-21：爲了完整起見，我們最終通過編寫代碼和重寫NHibernate方法來解決NHibernate的這個問題。在這個其他SO問題中的全部細節我問：NHibernate and Interceptors - measuring SQL round trip times。我預計這對於許多不同的ORM將是一個類似的方法。
您是否熟悉各種DMV和基於執行計劃統計信息顯示按持續時間，CPU，IO等進行頂級查詢的報告？也是什麼版本的SQL Server？如果2008有管理數據倉庫可能會有所幫助（儘管我猜測ORM發出的非參數化查詢可能會導致很多類似的查詢和計劃難以彙總結果） – 2011-01-26 17:24:33
有趣的問題，我期待着學習一些東西關於這個問題，因爲我沒有你的答案。 – HLGEM 2011-01-26 17:47:52
@Martin - 對不起，2008（編輯問題）。現在你提到DMV，它會響鈴，將進行調查。目前該應用程序基於SQL 2000，但下一個版本被提升至2008年。而不是*對* 2000解決方案感到困擾。儘管一旦我們有了這個查詢，我們該如何追溯到通過ORM層導致問題的模塊呢？ – 2011-01-26 18:27:04