select c.last_execution_time , --最後一次執行時間
c.execution_count , --執行次數
c.total_logical_reads , --總邏輯讀（次）
c.total_logical_writes , --總邏輯寫（次）
c.total_elapsed_time , --總執行（執行）語句使用的時間（微秒）
c.last_elapsed_time , --最後執行（執行）語句使用的時間（微秒）
q.[text] , --對應的sql語句
c.total_worker_time / 1000000 total_worker_time_second --c.total_worker_time 總工作時間（微秒）
from ( select top 50
qs.*
from sys.dm_exec_query_stats qs
order by qs.total_worker_time desc
) as c
order by c.last_elapsed_time desc;
1、將執行次數多、頻率高、單次執行周期長的語句摘出來，如圖：該語句共計執行495次，最後一次執行時間約1秒，像這樣的sql優化之後可縮短不少總執行時間。（ps：當然前面執行次數少執行時間長的肯定也是需要優化的，這種都是安全隱患，指不定哪天系統奔潰了就因為一條sql語句）
2、優化語句，上圖sql語句如下，執行時間約1秒，經分析查詢條件order_time未加索引，會對訂單表做全表檢索，資料量大概100萬左右。
3、對表字段order_time建立索引之後，執行時間縮至203毫秒（平均200ms），如圖：
4、發現查詢值為count（*），條件中未用到ri、rp、sg、po表，故將這些關聯表刪除，刪除之後執行時間變為178毫秒（平均180ms），如圖：
5、這裡表關聯條件 oi.company_id = ci.id不會出現關聯不到的情況，故可以將left join改為inner join，修改後執行時間變為83毫秒（平均80ms），如圖：
6、找到**中的sql語句進行調整。
這裡講的比較細，每條需要優化的sql語句都可能存在不一樣的情況，處理的方式也多種多樣，需要根據實際情況調整。
sqlserver 優化語句小助手
我們在開發的過程中，經常會遇到一些效能差的問題，此刻我的解決思路一般是，首先在瀏覽器端監控檢視是哪乙個呼叫的方法占用的時間比較長如下圖，然後會根據方法定位到具體的方法，然後可能是自己寫的遺傳sql語句，此刻就是分析你的語句到底哪一句占用的時間比較長了。1.瀏覽器端監控方法呼叫及其響應的時間 以為例 ...
SQL Server效能優化（6）查詢語句建議
1.如果對資料不是工業級的訪問 允許髒讀 在select裡新增 with nolock select top10 idfrom measure heat with nolock 2.限制結果集的資料量，如使用top 100等來限制返回的行數。實在不行，在資料庫內分頁。3.查詢時不要返回不需要的行 列...
SQL 語句優化 OR 語句優化案例
從上海來到溫州，看了前幾天監控的sql語句和資料變化，發現有一條語句的io次數很大，達到了150萬次io，而兩個表的資料也就不到20萬，為何有如此多的io次數，下面是執行語句 select ws.nodeid,wi.laststepid,wi.curstepid from workflowinfo ...