參考：https://www.jb51.net/article/51904.htm

Sql Server查詢緩慢的原因有很多，比如服務(wù)器資源不足、網(wǎng)絡(luò)故障、查詢語句不夠優(yōu)化，I/O問題等等，以及數(shù)據(jù)庫索引問題

一、查詢思路

• 1.想要判斷數(shù)據(jù)庫查詢緩慢的問題，可以使用如下語句，可以列出查詢語句的平均時間，總時間，所用的CPU時間等信息

SELECT creation_time N'語句編譯時間'
  ,last_execution_time N'上次執(zhí)行時間'
  ,total_physical_reads N'物理讀取總次數(shù)'
  ,total_logical_reads/execution_count N'每次邏輯讀次數(shù)'
  ,total_logical_reads N'邏輯讀取總次數(shù)'
  ,total_logical_writes N'邏輯寫入總次數(shù)'
  , execution_count N'執(zhí)行次數(shù)'
  , total_worker_time/1000 N'所用的CPU總時間ms'
  , total_elapsed_time/1000 N'總花費時間ms'
  , (total_elapsed_time / execution_count)/1000 N'平均時間ms'
  ,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
  ((CASE statement_end_offset
  WHEN -1 THEN DATALENGTH(st.text)
  ELSE qs.statement_end_offsetEND
  - qs.statement_start_offset)/2) + 1) N'執(zhí)行語句'
  FROM sys.dm_exec_query_stats AS qs
  CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
  where SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
  ((CASE statement_end_offset
  WHEN -1 THEN DATALENGTH(st.text)
  ELSE qs.statement_end_offsetEND
  - qs.statement_start_offset)/2) + 1) not like'%fetch%'
  ORDER BY total_elapsed_time / execution_count DESC;

• 2.列出數(shù)據(jù)庫每個表的數(shù)據(jù)量，并且需要運維人員對業(yè)務(wù)足夠了解，知道大概哪些表是查詢量最多的，可以查看“排在前面的表的磁盤使用情況”：

• 3.查看表碎片的情況，可以使用命令
  DBCC SHOWCONTIG
  可以看到該表掃描密度只有33.52%（最佳狀態(tài)是100%，每個表頁都寫滿數(shù)據(jù)），遠(yuǎn)遠(yuǎn)低于最佳計數(shù)，也就是說這個表的利用率很低，本來掃描一頁 就能出結(jié)果，現(xiàn)在可能需要掃描三頁，增加了查詢時間；而邏輯碎片和區(qū)碎片都很多（一般認(rèn)為超過30%就需要優(yōu)化了），也就是說同樣一頁，數(shù)據(jù)很少而碎片很 多，占用了過多的數(shù)據(jù)庫資源。

• 4.根據(jù)你對業(yè)務(wù)的了解，找出查詢最多的表，對比他的數(shù)據(jù)，查詢時間，和碎片程度可以判斷出該表是否需要整理碎片，重建索引，以提高數(shù)據(jù)庫性能。
  重建索引的語句為：
  use[數(shù)據(jù)庫名]
  ALTER INDEX ALL ON [表名稱] REBUILD;
  重建后，同樣的一張表NWME_Company_Index，再次查詢表碎片情況的結(jié)果如下：
  可以看到密度已經(jīng)變?yōu)?6.9%，而邏輯碎片幾乎沒有了。

• 5.現(xiàn)在可以看一下整理碎片后，是否真的對查詢性能優(yōu)化了，再次運行第一點列出的命令查看可以發(fā)現(xiàn)，大部分查詢語句所用的平均時間都下降了接近一半：
  現(xiàn)在可以到前臺實際體驗優(yōu)化后的效果了。