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