最有效的數(shù)據(jù)庫管理員不會根據(jù)表面上看起來很明顯的東西做出草率的決定。他們更深入地研究問題，以便在采取行動之前更好地了解根本原因。
這是優(yōu)化 SQL Server 的一種非常重要的方法。以下是我看到的前五個 SQL Server 性能問題，以及為什么永遠(yuǎn)不要草率假設(shè)并對所有事情應(yīng)用批判性鏡頭很重要。
1. Tempdb PAGELATCH 爭用
這個日益普遍的問題通常是由于系統(tǒng)大量使用 tempdb 進(jìn)行某種類型的提取、轉(zhuǎn)換和加載 (ETL) 過程。如果它是一個持續(xù)的“實(shí)時”風(fēng)格的 ETL 過程，這尤其常見。
癥狀可能會有所不同，但有些事情總是相同的：tempdb 中的高 PAGELATCH 等待和使用 tempdb 的進(jìn)程記錄的性能不佳。我通常會遵循 Performance Advisor 中對 Top SQL 的等待，并查看大量使用 Top SQL 中列出的臨時表的查詢。這些查詢通常以毫秒為單位運(yùn)行，并且永遠(yuǎn)不應(yīng)計(jì)入服務(wù)器的“頂級 SQL”。這可能會讓人們覺得這些查詢是問題的很大一部分，但事實(shí)并非如此。查詢是真正問題的受害者。
一旦懷疑是這種情況，我通常會跳轉(zhuǎn)到 Performance Advisor 中的“磁盤活動”選項(xiàng)卡以查看 tempdb 的配置方式。大多數(shù)時候我實(shí)際上看到的是同樣的事情：一個繁忙的臨時數(shù)據(jù)庫，定義了一個數(shù)據(jù)文件。從這里開始，我通常會建議重新配置 tempdb。
2. 期待自動更新統(tǒng)計(jì)信息以保持統(tǒng)計(jì)更新
這里的問題是觸發(fā)自動統(tǒng)計(jì)更新的閾值在大多數(shù)情況下最終是相同的，即使對于非常大的表也是如此。閾值約為表中行的 20%。在一個非常大的表上，需要大量數(shù)據(jù)更改才能觸發(fā)更新。
之所以列出該列表，是因?yàn)閿?shù)據(jù)庫管理員似乎真的很驚訝地發(fā)現(xiàn)自動更新并沒有像顧名思義那樣處理事情。然后也有許多 DBA 認(rèn)為應(yīng)該由他們的維護(hù)工作來處理。然后在查看維護(hù)后，他們大部分時間都在進(jìn)行索引重組，這也不會更新統(tǒng)計(jì)信息（盡管重建會）。
教訓(xùn)是密切關(guān)注統(tǒng)計(jì)數(shù)據(jù)并確保它們定期更新，尤其是在越來越普遍的大表上。另一種選擇是使用跟蹤標(biāo)志 2371 來實(shí)際更改用于觸發(fā)更新的公式。
3. CXPACKET 等待類型
這是我在大型 SQL Server 系統(tǒng)上看到的一種最常見的等待類型，當(dāng)有人讓我研究它們的查詢性能時。
可悲的是，我仍然看到很多人做出最初的假設(shè)，即應(yīng)該通過讓查詢或整個 SQL Server 將最大并行度 (MAXDOP) 設(shè)置為 1 來解決問題。 通常，可以通過適當(dāng)?shù)乃饕齺硖幚韱栴}或統(tǒng)計(jì)維護(hù)。也可能是為此查詢緩存的計(jì)劃不是最佳的，您可以使用 sp_recompile 將其標(biāo)記為重新編譯，在查詢級別設(shè)置重新編譯，或者只是使用帶有計(jì)劃句柄的 DBCC FREEPROCCACHE 驅(qū)逐計(jì)劃。最好在決定將 MAXDOP 更改為 1 之前用盡這些選項(xiàng)，因?yàn)槟赡軙跊]有意識到的情況下丟棄大量處理能力。
4. 誤解“超時在...完成之前到期”
這個是巨大的。除了一些非常極端的行為之外，您可能會為 SQL Server 處理兩種基本類型的超時。這些是連接超時和操作（或查詢）超時。在這兩種情況下，這些值都是由連接到 SQL Server 的客戶端設(shè)置的。在服務(wù)器端，有一個遠(yuǎn)程查詢超時設(shè)置，但這是非常極端的情況。
操作超時是最常見的，也可能是我遇到的最容易被誤解的情況。原因歸結(jié)為一個簡單的因素：執(zhí)行命令的客戶端設(shè)置了等待命令完成的最長時間。如果在完成之前達(dá)到此最大值，則中止命令。從客戶端引發(fā)錯誤。
通常，超時錯誤會引發(fā)恐慌模式，因?yàn)殄e誤看起來很嚇人。實(shí)際情況是，這與在 SQL Server Management Studio 中點(diǎn)擊停止按鈕沒有太大區(qū)別，因?yàn)椴樵兓ㄙM(fèi)的時間太長。它將在錯誤 = 2（中止）的探查器跟蹤中顯示完全相同。
像這樣的超時告訴我們查詢花費(fèi)的時間比預(yù)期的要長。我們應(yīng)該進(jìn)入“性能調(diào)整”模式而不是“某些東西壞了”模式。來自客戶端的錯誤信息是關(guān)于您可以開始集中調(diào)整工作的位置的好信息。
對于將 RDBMS 用于存儲庫的任何系統(tǒng)來說都是如此。您的數(shù)據(jù)庫時不時地需要一些 TLC。沒有它，您可能確實(shí)會遇到客戶的一些超時。我們花費(fèi)大量時間在查詢發(fā)布之前對其進(jìn)行性能優(yōu)化，但適當(dāng)?shù)木S護(hù)將確保它們繼續(xù)按預(yù)期運(yùn)行。
5. 內(nèi)存壓力
這是一個很大的問題，因?yàn)槲医?jīng)常看到它，也因?yàn)樗?jīng)常被誤認(rèn)為磁盤性能不佳。
SQL Server 中有很多緩存，但最著名的是數(shù)據(jù)緩存（又名緩沖池）。描述數(shù)據(jù)緩存最簡單的方式是它是存儲在內(nèi)存中的數(shù)據(jù)，而不是持久化到磁盤。將大量數(shù)據(jù)長期存儲在內(nèi)存中是可取的，因?yàn)樵趦?nèi)存中處理數(shù)據(jù)通常比必須執(zhí)行物理 I/O 快得多。
通常，記憶壓力表現(xiàn)為幾種不同的癥狀。當(dāng)單獨(dú)查看時，其中一些癥狀可能會導(dǎo)致您得出錯誤的、有時代價(jià)高昂的結(jié)論。
兩個誤導(dǎo)性癥狀是您可能會開始看到整個磁盤子系統(tǒng)的延遲高于正常延遲，并且您可能會開始看到與磁盤活動相關(guān)的異常高等待。如果您只查看這兩個癥狀，您可能會得出結(jié)論，您需要在您的磁盤系統(tǒng)上工作。
這就是為什么在一個儀表板上顯示所有相關(guān)指標(biāo)如此重要的原因。您必須著眼于更大的圖景，將與內(nèi)存相關(guān)的數(shù)據(jù)與磁盤活動和等待一起可用，有助于更清晰地了解真正發(fā)生的情況。
通常，我會看到此服務(wù)器的 PLE（頁面預(yù)期壽命）相當(dāng)?shù)汀＞彌_區(qū)緩存越大，PLE 的“臨界”閾值就越高。流入和流出緩沖區(qū)的數(shù)據(jù)越多，發(fā)生“流失”時的情況就越糟。另一個考慮因素是非均勻內(nèi)存訪問 (NUMA)。當(dāng)涉及多個 NUMA 節(jié)點(diǎn)時，計(jì)算 PLE 計(jì)數(shù)器的方式可能會導(dǎo)致此值非常具有誤導(dǎo)性。
我通常還會看到持續(xù)較高的惰性寫入器活動和 SQL Server 頁面錯誤（SQL Server 進(jìn)入磁盤）。有時我會看到我所說的緩沖區(qū)撕裂。當(dāng)數(shù)據(jù)緩沖區(qū)上下波動時會發(fā)生這種情況，經(jīng)常在 Performance Advisor 的歷史圖表上創(chuàng)建鋸齒狀（或撕裂）邊緣。我還可能看到異常大的計(jì)劃緩存減少了數(shù)據(jù)緩存的可用內(nèi)存。
所有這些因素共同構(gòu)成了記憶壓力。有多種方法可以處理它們，但重要的是這不是磁盤問題。我不會根據(jù)這種情況打電話給您的存儲區(qū)域網(wǎng)絡(luò)聯(lián)系人并訂購新硬件。一旦控制了內(nèi)存壓力情況，SQL Server 就不需要那么多去磁盤了，一些與磁盤相關(guān)的癥狀可能會完全消失！
結(jié)論
隨著組織面臨新的數(shù)據(jù)庫需求，首要的 SQL Server 性能問題/主題將繼續(xù)發(fā)展。如果從所有這些潛在問題中得出一個主要結(jié)論，那就是始終考慮性能的全貌，因?yàn)槊撾x上下文查看一個因素可能會嚴(yán)重限制您對解決方案的選擇。
