SQL Server進行開發和部署的。如今，SQL Server已經成為現代業務應用的基石，并且它還是很多大公司業務流程的核心。SQL Server的應用范圍很廣，包括生產過程中的業務線應用，內部客戶關系管理和決策支持系統，以及面向用戶的電子商務和網絡自服務應用等。因此，SQL Server性能和可伸縮性具有很高的優先級，而且提供最優的SQL Server性能和擴展性也是所有SQL Server DBA們的關鍵工作之一。

然而，很多SQL Server系統的性能和擴展性并不理想，這通常是由糟糕的數據庫設計，索引設計和SQL Server系統對工作負載的不適當配置造成的。因為任何大型SQL Server工程的開發都以實現功能為主要目的，至于性能和擴展性經常被當做一種事后才處理的東西。

雖然對SQL Server系統的性能問題進行故障診斷困難重重，但是如果能用相對較少的時間投入，換取顯著的性能提升，又何樂而不為呢。

硬件性能瓶頸
 

內存

內存對SQL Server性能的影響勝過任何其他硬件。因此，對SQL Server系統的內存使用情況進行定期監視以確保內存的可用百分比高于20%是很有必要的。如果用戶遭遇性能問題，同時可用內存百分比低于20%,那么此問題一定是內存分配不足導致的。這要求技術人員密切關注顯示平均頁面預期壽命的性能計數器，并確保平均頁面預期壽命總是高于300秒（5分鐘）。一旦放生少于此標準的情況，就說明要么是糟糕的索引設計導致了磁盤輸入/輸出（I/O）的增加，要么就是對內存的利用效率很低，或者是實際的內存不足。技術人員需要監視SQL Server系統上的分頁率，并確保它們常規為1000頁每秒。檢查PerfMon object MSSQL Buffer Manager（性能監視對象MSSQL緩沖管理器）和Memory Performance Counters（內存性能計數器）。

同樣，還要監視計數器，即PerfMon object SQL Server Memory Manager Counters中的Memory Grants Pending.此計數器顯示的是每秒鐘等待工作負載分配的進程總數。一般來講，小型OLTP事務不需要大內存分配。對一個OLTP事務來說，任何大于零的內存分配都說明SQL Server系統存在內存不足。

解決內存瓶頸的途徑之一是找出內存高耗進程，這可以確認諸如內存泄漏之類潛在的應用程序問題。你還可以通過檢查查詢優化性能以消耗更少的內存。另外一種方法就是給SQL Server增加更多的物理內存來擴展升級SQL Server環境。擴展升級通常是解決任何與內存相關的性能瓶頸的濟世良方。

磁盤I/O使用

對比其他的硬件資源，存儲輸入/輸出通常是SQL Server中最慢的系統資源。因此，監視存儲系統以確定存儲是否成為一個影響性能的瓶頸是十分重要的。如果是，那么下個步驟就是要調查是否能夠優化存儲系統的設計和配置以獲得擴展性和高性能。檢查Average Disk Sec/Read（秒均磁盤讀取）和Average Disk Sec/Write （秒均磁盤寫入）的PerfMon磁盤計數器。確保OLTP系統和更高決策支持系統的一個讀或寫的時間在理想情況下少于12毫秒。

與內存一樣，解決磁盤I/O性能瓶頸最簡單的方法就是擴展升級SQL Server環境，即用更快的磁盤替換現有磁盤，可以更好地應對I/O負載和分配I/O負載到多個軸上。同時還要定期整理磁盤數據。

CPU

CPU性能瓶頸的發生有諸多原因。它們包括非理想的查詢計劃，應用程序或是數據庫的設計缺陷，糟糕的SQL Server配置或是硬件資源的不足。技術人員可以對Processor Queue Length（處理器隊列長度）的PerfMon operation system CPU（PerfMon操作系統CPU）和處理器計數器進行檢查以驗證正在等待CPU周期的線程數在八個以內。如果這一數字大于12,那就意味著CPU產生了性能問題。

在確認了某個CPU瓶頸之后，便可以使用sys.dm_os_wait_stats動態管理視圖（DMV）來確認對CPU來說排前十的性能最差的查詢，如下所示。
SELECT TOP 10 （a.total_worker_time / a.execution_count） AS [Avg_CPU_Time]
,Convert（VARCHAR, Last_Execution_Time） AS [Last_Execution_Time]
,Total_Physical_Reads
,SUBSTRING（b.TEXT, a.statement_start_offset / 2, （
CASE
WHEN a.statement_end_offset = - 1
THEN len（convert（NVARCHAR（max）， b.TEXT）） * 2
ELSE a.statement_end_offset
END - a.statement_start_offset
） / 2） AS [Query_Text]
,dbname = Upper（db_name（b.dbid））
,b.objectid AS 'Object_ID', B.*
FROM sys.dm_exec_query_stats a
CROSS APPLY sys.dm_exec_SQL_text（a.SQL_handle） AS b
ORDER BY [Avg_CPU_Time] DESC

接著，你可以對這些查詢和底層索引進行調優以解決CPU瓶頸。同時，對你的SQL Server進行配置以使用所有可用的CPU機器。你還可以通過添加額外的CPU或用更快的CPU升級一個新的服務器來擴展你的SQL Server系統。

數據庫設計問題

高度規范化的數據庫

糟糕的數據庫設計會導致數據庫性能不足。例如，高度規范化的數據庫是與復雜關系連接相關聯的。這就造成了長時間執行查詢對諸如CPU,內存，和磁盤I/O之類系統資源的浪費。顯然，一個高度規范化的數據庫會讓SQL Server和數據庫性能顯著降低。編寫高效查詢的一般規則就是如果一個操作需要五個或者更多的表連接，就要對數據庫進行重新設計。

重復和未使用的索引

索引是解決很多性能問題的殺手锏，但是在頻繁更新的表上擁有過多的索引會招致額外開銷，因為SQL Server在執行插入/更新/刪除操作期間會執行額外的工作以保持索引處于最新狀態。這就意味著在更新基于索引數量和復雜度的表中數據的時候，SQL Server數據庫引擎需要更多的時間。同時，索引維護也會增加CPU和I/O使用，這會在一個密集寫入的系統中對性能造成損害。因為任何重復和冗余的索引對系統資源來說毫無意義，所以需要將它們移除。

在SQL Server中，我們可以使用sys.dm_db_index_usage_stats DMV來識別未使用的索引。DMV給出了一個索引是如何用于解析查詢的相關統計數據。另外，你還可以執行Database Engine Tuning Advisor（數據庫引擎調優顧問DTA）來識別未使用的索引。