【編者的話】

說起“調優”，可能會讓很多技術人員心頭激情澎湃，也可能會讓很多人感覺苦惱。SQL Server的性能調優，是個很寬廣的話題。本文簡要介紹一個SQL Server性能調優方法論，并為大家介紹幾款常用工具。

早期的文章中，曾經提到過性能調優中的DETECT方法論，這里先簡單回顧一下DETECT方法論。

• Discover the problem ：發現問題
• Explore the conditions：探究原因
• Track down possible approaches：提供可能解決的方式
• Execute the most likely approach：執行***可能的解決方式
• Check of success ：確認是否成功(如果沒有成功，反復執行上面的步驟)
• Tie up loose ends ：完成剩余工作

首先看 Discover ，發現問題

• 是否已經簡潔的描述了整個問題?
• 用戶當前的基線在哪里?
• 用戶期望的是什么?
• 并不是所以的問題都可以解決的

再看Explore，探究原因

取得證據

• SqlProfiler跟蹤 /Sql Trace
• DMV 和 DMF
• ShowPlan執行計劃輸出
• 各種系統的性能計數器
• sqlserver特有的性能計數器

檢查最明顯的問題(探究問題先不要深入)

Track down 提供可能的解決方式

***階段，建立證明假設的計劃

第二階段，建立解決問題的計劃

執行最有可能的解決方案

***階段，執行測試計劃來證明你的假設

第二階段，執行解決問題的方案

Check，確認成功與否

***階段

你的計劃證明了你的假設，還是推翻了他?

第二階段

• 你的計劃是否改變了現象?
• 瓶頸是否轉移了?
• 解決方案是否符合你原先的目標?

記住：該過程通常是遞歸反復執行的

Tie up 完成剩余工作，收尾

• 性能調優是否達會有無法預計的邊際效應?
• 所做的修改是否真正解決了問題，會不會短時間又碰到相同問題?
• 還需要做哪些跟蹤的工作?

上面說了那么方法論，雖然很枯燥，但是還是有指導意義的。下面來點實際的知識。

#p#

瓶頸分析

瓶頸的定義

瓶頸=需求達到的速率>實際處理量

流程：

• 決定是卡在哪一個點上
• 決定在隊列中等待的狀況
• 減少輸入(需求達到的速率)或是增加同時的處理量
• 決定收益
• 決定成本

常見瓶頸的監視任務

• 監視內存占用
• 監視線程和CPU使用
• 監視硬盤IO
• 監視低性能查詢
• 監視存儲過程、sql和用戶活動
• 監視當前鎖定和用戶互動

建立性能調優的計劃

性能調優是反復的過程，一而再，再而三的循環，一次又一次趨近的修正，要利用文字記錄以說明

• 理出頭緒，突顯問題并證明
• 系統的逼近目標
• 有共識，知道彼此談論的標地
• 能夠匯總比較
• 當系統出現的多個瓶頸，找出最關鍵的，成本***的先執行調優

執行性能調優的計劃時，要確定對線上生產環境的影響

方法論--縮小

性能調優中常用的工作

• windows事件查看器
• windows系統監視器
• SSMS中的當前活動窗口
• T-SQL工具
• Sql Profiler
• 查詢分析器
• 數據庫引擎優化顧問

windows事件查看器，主要是查看以下的事件日志

• windows應用程序日志
• windows系統日志
• windows安全日志

windows系統監視器能夠跟蹤：

• sql server I/O
• sql server 內存
• sql server用戶
• sql server 鎖
• 復制活動

SSMS中的活動監視器：

• 活動用戶任務
• 資源等待
• 數據文件I/O
• 耗費大量資源的查詢

T-SQL工具：

• 系統存儲過程
• 全局變量
• T-SQL語句
• DBCC
• 跟蹤標記
• DMF/DMF

Sql Profiler，跟蹤并捕獲sqlserver事件

• 選擇需要跟蹤的事件
• 選擇跟蹤模版
• 選擇需要捕獲的數據
• 有意義對數據進行分類

查詢分析器

• 顯示查詢執行計劃
• 顯示服務器跟蹤
• 顯示服務器端統計信息
• 顯示客戶端統計信息

數據庫引擎優化顧問

• 分析瓶頸
• 給出建議sql語句(索引和統計信息)

博文出處：http://blog.csdn.net/dinglang_2009/article/details/46480859