我們的應用程式中的一個查詢出現了性能問題，需要 20 秒才能運行。使用 azure 資料作業室，我們找出了長時間運行的 SQL，然后最終將其追溯到執行的物體框架查詢。
我有一個想法，在我們的代碼中添加一個日志記錄函式，在物體框架代碼中完成任何資料訪問（插入、選擇、洗掉、更新等）之前呼叫它。
該函式所做的只是簡單地執行“Select user_functionname_now”sql 陳述句。
然后在 azure data studio profiler 中我們會看到：
圖片告訴我，用戶運行了加載發票功能，耗時 2717 毫秒。
當然，如果您有 100 個用戶在應用程式中執行操作，日志可能會有些混亂，但要弄清楚長時間運行的查詢是從代碼中的哪個位置執行的，這將大有幫助。
我還想我們可以為每個查詢運行添加一個固定列，以便您可以看到如下內容：
但是添加列的問題是每次運行查詢時都會回傳額外的資料，這需要在 SQL 服務器和應用程式之間來回傳遞更多資料，這肯定不是一件好事。
所以我的問題是：在每個 CRUD 呼叫之前添加“選擇 XYZ”是一個壞主意嗎？如果我們將此日志記錄呼叫添加到執行查詢的部分或全部代碼中，是否會導致我沒有考慮過的性能問題/速度下降？
uj5u.com熱心網友回復：
我不認為在您的情況下使用任何“選擇...”是合理的。
也許，SET CONTEXT_INFO或sp_set_session_context會更好。
uj5u.com熱心網友回復：
這是 EF查詢標簽適用的場景。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/351712.html
標籤：sql-server sql-server-profiler 蔚蓝数据工作室
上一篇：如何避免重復相同的查詢？