SQLServer中常見的性能問題有哪些

這篇“SQLServer中常見的性能問題有哪些”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“SQLServer中常見的性能問題有哪些”文章吧。

1. Tempdb PAGELATCH 爭用

這個日益普遍的問題通常是由于系統大量使用 tempdb 進行某種類型的提取、轉換和加載 (ETL) 過程。如果它是一個持續的“實時”風格的 ETL 過程，這尤其常見。

癥狀可能會有所不同，但有些事情總是相同的：tempdb 中的高 PAGELATCH 等待和使用 tempdb 的進程記錄的性能不佳。我通常會遵循 Performance Advisor 中對 Top SQL 的等待，并查看大量使用 Top SQL 中列出的臨時表的查詢。這些查詢通常以毫秒為單位運行，并且永遠不應計入服務器的“頂級 SQL”。這可能會讓人們覺得這些查詢是問題的很大一部分，但事實并非如此。查詢是真正問題的受害者。

一旦懷疑是這種情況，我通常會跳轉到 Performance Advisor 中的“磁盤活動”選項卡以查看 tempdb 的配置方式。大多數時候我實際上看到的是同樣的事情：一個繁忙的臨時數據庫，定義了一個數據文件。從這里開始，我通常會建議重新配置 tempdb。

2. 期待自動更新統計信息以保持統計更新

這里的問題是觸發自動統計更新的閾值在大多數情況下最終是相同的，即使對于非常大的表也是如此。閾值約為表中行的 20%。在一個非常大的表上，需要大量數據更改才能觸發更新。

之所以列出該列表，是因為數據庫管理員似乎真的很驚訝地發現自動更新并沒有像顧名思義那樣處理事情。然后也有許多 DBA 認為應該由他們的維護工作來處理。然后在查看維護后，他們大部分時間都在進行索引重組，這也不會更新統計信息（盡管重建會）。

教訓是密切關注統計數據并確保它們定期更新，尤其是在越來越普遍的大表上。另一種選擇是使用跟蹤標志 2371 來實際更改用于觸發更新的公式。

3. CXPACKET 等待類型

這是我在大型 SQL Server 系統上看到的一種最常見的等待類型，當有人讓我研究它們的查詢性能時。

可悲的是，我仍然看到很多人做出最初的假設，即應該通過讓查詢或整個 SQL Server 將最大并行度 (MAXDOP) 設置為 1 來解決問題。 通常，可以通過適當的索引來處理問題或統計維護。也可能是為此查詢緩存的計劃不是最佳的，您可以使用 sp_recompile 將其標記為重新編譯，在查詢級別設置重新編譯，或者只是使用帶有計劃句柄的 DBCC FREEPROCCACHE 驅逐計劃。最好在決定將 MAXDOP 更改為 1 之前用盡這些選項，因為您可能會在沒有意識到的情況下丟棄大量處理能力。

4. 誤解“超時在...完成之前到期”

這個是巨大的。除了一些非常極端的行為之外，您可能會為 SQL Server 處理兩種基本類型的超時。這些是連接超時和操作（或查詢）超時。在這兩種情況下，這些值都是由連接到 SQL Server 的客戶端設置的。在服務器端，有一個遠程查詢超時設置，但這是非常極端的情況。

操作超時是最常見的，也可能是我遇到的最容易被誤解的情況。原因歸結為一個簡單的因素：執行命令的客戶端設置了等待命令完成的最長時間。如果在完成之前達到此最大值，則中止命令。從客戶端引發錯誤。

通常，超時錯誤會引發恐慌模式，因為錯誤看起來很嚇人。實際情況是，這與在 SQL Server Management Studio 中點擊停止按鈕沒有太大區別，因為查詢花費的時間太長。它將在錯誤 = 2（中止）的探查器跟蹤中顯示完全相同。

像這樣的超時告訴我們查詢花費的時間比預期的要長。我們應該進入“性能調整”模式而不是“某些東西壞了”模式。來自客戶端的錯誤信息是關于您可以開始集中調整工作的位置的好信息。

對于將 RDBMS 用于存儲庫的任何系統來說都是如此。您的數據庫時不時地需要一些 TLC。沒有它，您可能確實會遇到客戶的一些超時。我們花費大量時間在查詢發布之前對其進行性能優化，但適當的維護將確保它們繼續按預期運行。

5. 內存壓力

這是一個很大的問題，因為我經常看到它，也因為它經常被誤認為磁盤性能不佳。

SQL Server 中有很多緩存，但最著名的是數據緩存（又名緩沖池）。描述數據緩存最簡單的方式是它是存儲在內存中的數據，而不是持久化到磁盤。將大量數據長期存儲在內存中是可取的，因為在內存中處理數據通常比必須執行物理 I/O 快得多。

通常，記憶壓力表現為幾種不同的癥狀。當單獨查看時，其中一些癥狀可能會導致您得出錯誤的、有時代價高昂的結論。

兩個誤導性癥狀是您可能會開始看到整個磁盤子系統的延遲高于正常延遲，并且您可能會開始看到與磁盤活動相關的異常高等待。如果您只查看這兩個癥狀，您可能會得出結論，您需要在您的磁盤系統上工作。

這就是為什么在一個儀表板上顯示所有相關指標如此重要的原因。您必須著眼于更大的圖景，將與內存相關的數據與磁盤活動和等待一起可用，有助于更清晰地了解真正發生的情況。

通常，我會看到此服務器的 PLE（頁面預期壽命）相當低。緩沖區緩存越大，PLE 的“臨界”閾值就越高。流入和流出緩沖區的數據越多，發生“流失”時的情況就越糟。另一個考慮因素是非均勻內存訪問 (NUMA)。當涉及多個 NUMA 節點時，計算 PLE 計數器的方式可能會導致此值非常具有誤導性。

我通常還會看到持續較高的惰性寫入器活動和 SQL Server 頁面錯誤（SQL Server 進入磁盤）。有時我會看到我所說的緩沖區撕裂。當數據緩沖區上下波動時會發生這種情況，經常在 Performance Advisor 的歷史圖表上創建鋸齒狀（或撕裂）邊緣。我還可能看到異常大的計劃緩存減少了數據緩存的可用內存。

所有這些因素共同構成了記憶壓力。有多種方法可以處理它們，但重要的是這不是磁盤問題。我不會根據這種情況打電話給您的存儲區域網絡聯系人并訂購新硬件。一旦控制了內存壓力情況，SQL Server 就不需要那么多去磁盤了，一些與磁盤相關的癥狀可能會完全消失！

以上就是關于“SQLServer中常見的性能問題有哪些”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。