SQL Server性能優化案例報告收藏
1. 問題分析
1.1 現象描述
某企業客戶內部知識管理系統基於微軟SharePoint服務器產品並進行了應用擴展開發，NLB負載均衡部署，後臺數據庫採用SQL Server 2000 企業版，雙核 4C 8G內存兩節點羣集。在兩三年的使用過程中，隨着系統用戶的增多，出現了數據庫服務器CPU佔用過高的情況，導致前端訪問響應速度慢，經常超時等問題。
1.2 性能計數器分析
用戶連接
經過對SQL Server關鍵性能指標的採集和分析，發現用戶連接指標數值過大。用戶連接的數據基本保持在700-1000之間，不僅是在忙時段(AM:10)，且在閒時段(PM: 6)也基本保持不變，基本可以確定是數據庫連接池配置不當或有代碼沒有釋放可用連接，需要通過應用代碼進行問題排查。
鎖請求/秒
經過向用戶的瞭解，該系統爲多數讀取，少數寫入的系統，但從性能計數器的觀測值發現鎖請求/秒的指標值平均約爲158418.485，最高值可達到558870.266，鎖操作總體過大，應該從應用層面進行分析優化。
完全掃描/秒
完全掃描/秒計數器指示有多少不使用索引而進行的全表掃描，測量過程中顯示平均值達到100左右，最高值達到832.998，應分析SQL查詢語句和數據庫索引的對應關係，追加必要的索引以減少全表掃描的次數。
1.3 SQL工具分析
通過使用SQL 事件探查器和查詢分析器等工具對SQL Server內部語句執行的性能狀況列出了明細，並可將其中的CPU佔用較高的任務列出，如第一行顯示的大量數據連接導致CPU佔用較高、第二行復雜子查詢Join下存在部分索引未創建、wf_Instance_track表有大量過期的歷史數據時變慢等問題。
1.4 應用代碼分析
經過對系統源代碼的粗略分析，發現以下一些問題：
a. SqlHelper中的GetConnection每次都是創建一個全新的數據庫連接而返回給調用代碼，導致連接無法被重用，每次全新創建也會增加服務器的負擔；
b. SqlHelper中的TestConnection每次都是創建一個全新的數據庫並且打開連接以測試連接的可用性，但是並不關閉就返回了。
c. AcceptUpdate中的SelectDb調用SqlHelper中的GetConnection獲得連接後進行數據庫查詢操作，但使用後並不關閉相應連接
d. AcceptUpdate中的UpdateDs調用SqlHelper中的GetConnection獲得連接後進行數據庫更新操作，但使用後並不關閉相應連接
e. ColSelect.aspx中的btn_Ok_ServerClick調用SqlHelper中的GetConnection獲得連接後進行數據庫更新操作，但使用後並不關閉相應連接
2. 優化方案
2.1 代碼優化
a. 由統一的代碼管理數據庫連接；
b. 使用數據庫連接池技術管理連接；
c. 使用後必須關閉數據庫連接；
d. 減少全新創建數據庫連接的次數（如減少不必要的TestConnection操作）
e. 優化SQL語句，減少表鎖；
f. 優化SQL語句，使查詢能儘量使用索引，減少全表掃描；
g. 適當使用臨時表，以減少SQL複雜度和子查詢；
h. 其他與數據庫性能有關的代碼排查；
2.2 數據庫優化
a. 創建經常被查詢用到的索引；
b. 適當調整SQL 實例性能相關的參數，以使資源使用最大化（但要考慮爲操作系統保留小部分資源）；
c. 備份和分離過期的歷史數據(如2006年的狀態跟蹤數據)，並建立定期的數據庫清理機制；
d. 定期觀測和記錄SQL性能計數器，瞭解性能狀況變化；
e. 升級到更高版本的SQL Server 產品，使用分區表等新技術能夠發揮更佳的服務器性能；
2.3 優化工作量估算
代碼優化和測試驗證：約需10-15個工作日（依原有代碼質量和數量決定）
數據庫優化和測試驗證：約需5-7個工作日
3. 優化實施
3.1 代碼優化
對代碼結構進行了性能分析，發現了一些代碼質量問題。
目錄名
文件名
方法名
App_Code/Site
AcceptUpdate.cs
SelectDb
App_Code/Site
AcceptUpdate.cs
UpdateDs
FramePage
ColSelect.aspx.cs
btn_Ok_ServerClick
App_Code
SqlHelper.cs
GetConnection
分析、修改、部署共計3人天
注：尚未對存儲過程進行優化
3.2 數據庫優化
對執行性能差但使用頻率較高的部分數據表進行了索引創建。
表名
索引列
索引名
略
分析、修改、部署和測試和報告共計5人天
4. 優化總結
4.1 性能對比
性能參考對象
優化前
優化後（閒）
優化後（忙）
說明
系統CPU利用率
86.235%左右
15.183%左右
45.583%左右
具體截圖如下圖1
完全掃描/秒
109.337左右
23.175左右
42.965左右
具體截圖如下圖2
鎖請求/秒
158418.485
37101.090
69444.232
具體截圖如下圖3
索引搜索/秒
98472
25374
43653
具體截圖如下圖4
用戶連接數
800-1200
541
820
圖0
圖1
圖2
圖3
圖4
4.2 待決問題
由於擔心影響業務邏輯的正確性和測試的複雜性，沒有對以下幾個部分進行優化：
1. 數據庫連接較多的問題，整體解決需要重新架構設計
2. 複雜度較高的SQL語句以及視圖的優化
3. 存儲過程的優化，防止表鎖
4. 工作流引擎內部機制不瞭解
4.3 系統建議
數據庫中表的數據量不是很大，單個簡單的查詢對整個系統的影響較小，較複雜的視圖或存儲過程優化有性能問題，隨着數據量的增大影響而更明顯，所以可定期清除不需要的歷史數據。
4.4 總結
通過增加對數據量較大的表以及查詢較頻繁的表增加索引，能夠減輕數據庫完全掃描的壓力，使CPU利用率下降。以上對比顯示，優化效果較明顯。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/redbirdli/archive/2009/03/11/3980810.aspx