現在很多使用者被資料庫的慢的問題所困擾，又苦於花錢請一個專業的DBA成本太高。軟體維護人員對資料庫的瞭解又不是那麼深入，所以導致問題遲遲不能解決，或只能暫時解決不能得到根治。開發人員解決資料問題基本又是搜遍百度各種方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。

　　　　怎麼樣讓瑣事纏身的程式維護人員，用最快的方式解決資料庫出現的問題？怎麼讓我們程式設計師的痛苦降低到最小...每天喝喝茶水，看看新聞平安度過一天呢？本系列重要通過工具講解下資料庫遇到的各種問題的表象及導致這樣問題的根本原因，讓定位問題更準確，解決問題思路更清晰！！

　　　　資料庫的效能好壞，對於終端使用者來說表現為點選的操作是否能夠快速響應，那麼反應到資料庫上就是語句執行時間是否夠短！

　　　　對用運維人員資料庫效能的表現，簡單可能看成CPU 、記憶體、磁碟三巨頭指標是否正常，前面講述了CPU和記憶體的基本診斷，為了方便閱讀給出系列文章的導讀連結：

　　　　本篇我們就講述最後的一位巨頭，看看磁碟能夠看出哪些問題！

廢話不多說，直接開整-----------------------------------------------------------------------------------------

磁碟也許對部分軟體運維人員來說，這東西不歸我管！愛咋咋地，速度慢就換SSD，壞了就再買！但是用在資料庫上的磁碟你怎麼能判斷出是，磁碟的問題？不是你資料庫其他問題導致的？磁碟壞了...一般的維護人員就哭了。

磁碟配置的建議　　　　　　　　

　　這裡的配置建議主要針對資料庫的磁碟使用，首先我們先明確下物理磁碟和邏輯磁碟的概念。

　　物理硬碟是硬體實體，即安裝在電腦機箱內的硬碟；
　　邏輯硬碟是指人為在物理上劃出分割槽以方便存取，管理裡面的檔案。

　　　注：當你感覺到磁碟有壓力，並且想用另一塊磁碟幫助分擔這個壓力時，你需要新增的是物理磁碟而不是邏輯磁碟。

　　　SQL SERVER中主要儲存在磁碟，並且主要影響你係統的檔案主要有：資料檔案、日誌檔案、tempDB資料檔案（tempDB日誌可以忽略），很多使用者的一臺伺服器上執行這多個數據庫或多例項，那麼針對你的現有資料庫規劃好磁碟分配是第一課！

　　   規劃磁碟分配的好處：假設你有兩個資料庫，業務操作都很繁忙，且讀/寫量都很大對磁碟的壓力都很大，那麼你自然會想到把他們分散到不同的磁碟上，這樣每個庫針對自己的磁碟讀/寫，不會互相影響且壓力相當於原來的1/2，從而可以提升磁碟操作的響應時間。

　　　資料庫磁碟該怎麼劃分？ 不同系統不同環境可能都不相同，下面給出一些簡單建議:

1. 按照檔案型別劃分：資料檔案、日誌檔案、tempDB檔案、備份檔案，分別放在一個物理磁碟（3塊物理磁碟）
2. 按照資料庫劃分：不同的業務資料庫（壓力大的）分別放在一個物理磁碟，tempDB和備份檔案各一個物理磁碟。

　　 上面的兩種分法是基本的劃分方式，但是根據系統壓力系統配置，均有不同情況。

　　 當你的資料庫壓力較小，或磁碟資源緊張可以做適當的合併。當你的資料庫特別大，並且有多個檔案組，也可以選擇把檔案組更進一步細分。

　　 類似於做了分割槽表，不同分割槽放在不同磁碟上，當需要多個分割槽資料時，可以利用IO並行提升效率。

如何區分你的磁碟是物理盤還是邏輯盤？

　　　　　　此例中C:H:是同一物理盤，Y:G:是同一物理盤，Y: 和 Z:都是單分割槽的物理盤。這次中共有4個物理磁碟

　　　　　　此例中每個都是一個單獨的物理磁碟

　　注：磁碟資訊可以通過系統資訊（執行-msinfo32）或通過效能計數器等等手段檢視。

　　下面看一個檔案劃分的例子: （例子使用上面C:D:E:F:J都是單獨物理磁碟）

　　　　　　　　　　tempDB放在F盤

　　　　　　　　　　資料檔案（.mdf）放在D盤，日誌檔案(.ldf)放在E盤

磁碟壓力的診斷和分析

 　　　　磁碟的壓力分析，主要使用下面幾個效能計數器 （針對單獨的物理盤，每個物理磁碟都會有一組）：

1. Avg. Disk Read Queue Length   讀佇列（越小越好，理想值 2 以下，佇列越高說明一個操作的響應時間越長）
2. Avg. Disk Write Queue Length  寫佇列（越小越好，理想值 2 以下，佇列越高說明一個操作的響應時間越長）
3. Avg. Disk sec/Read　　
4. Avg. Disk sec/Write
5. Disk Read Bytes/sec
6. Disk Write Bytes/sec

　　　　注：常規判斷系統磁碟壓力，通過讀寫佇列即可判斷，後面4個主要用於磁碟是否自身效能存在問題，本文不介紹。

　　　首先有哪些情況會對磁碟造成壓力？

1. 記憶體不足導致需要頻繁和磁碟互動　　（一般為主因）
2. 經常有大量冷資料需要從磁碟讀取，或經常有大批量髒頁一次寫入（checkpoint觸發）
3. 磁碟讀寫速度，不能滿足業務需要

為什麼記憶體不足會導致磁碟壓力大？　

　　　上一篇介紹了，記憶體這三個計數器是如何聯動的？

　　　　　　　　Page life expectancy 不被使用的頁在快取中停留的秒數，如果低說明記憶體壓力

　　　　　　　　Page Reads/sec　所要讀的資料不在記憶體中需要物理讀取

　　　　　　　　Lazy writes/sec　記憶體壓力時成批的重新整理老化緩衝區　

　　　磁碟的讀寫計數器：Avg. Disk Write Queue Length和Avg. Disk Read Queue Length和記憶體計數器很大程度上也是聯動的！

　　　當一個操作需要大量讀取資料，且資料頁不在快取中 ——》 那麼需要大量從磁碟讀取冷資料放入快取（Page Reads/sec 升高，Avg. Disk Read Queue Length升高） ——》快取有明顯壓力的時候Lazy writes/sec就會觸發（Lazy writes/sec升高），大批量的將老化的數據或快取計劃等刷出快取 ——》資料被清出快取（有髒頁需要寫入磁碟Avg. Disk Write Queue Length），那麼頁生命週期就會下降（Page life expectancy）

　　　　這內規律波動，記憶體壓力很有規律，記憶體壓力不過多介紹請參見上一篇。我們看看磁碟對應時間點的計數器是什麼樣子的？ 你能想想到麼？

　　　　是不是規律很強？這個例子展示了磁碟壓力和記憶體的聯動，也說明當你看到磁碟佇列很高的時候，不要輕易定位磁碟的問題，先看看當前系統記憶體是怎麼樣的狀態吧。

　　　藉助上一篇第二個，記憶體嚴重不足的例子：

　　　　我們來看看這麼大記憶體的壓力下，磁碟是什麼狀態，我想已經不用我說過多了。

　　　高能預警：佇列高可能，不那麼直觀的說明啥，下面我們來看一下這麼高佇列下的響應時間。每次和磁碟互動就要有1秒以上的磁碟響應時間（正常幾毫秒），那麼一個語句多次互動會是什麼樣的效果？

　　　----------------------------------------------------------------------------------

　　　至此我們瞭解到了，系統磁碟佇列高的根本原因是由於記憶體不足導致的，那麼我們拋開記憶體壓力不談，遇到上面的情況我們怎麼緩解磁碟壓力呢？？？

　　　那就是前面提到的用多塊磁碟分擔這個壓力或選用速度更快的。

　　　看一下這個系統的磁碟及資料庫檔案分佈

　　　可以看到這個伺服器只配置了一塊物理磁碟

　　　資料庫1

　　　資料庫2

　　　tempDB

　　　2個業務頻繁的大資料庫，資料檔案、日誌檔案和系統tempDB都在同一個磁碟上！

　　　如果有其他物理磁碟可以分攤壓力，讀寫佇列會有降低，讀寫響應時間也會大幅縮短，但我們不能忽略根本原因是記憶體的超大壓力！

-----------------------------------------------------------------------------------------------------

　　總結：現在硬體成本越來越低，很多使用者都採用SSD或高階儲存等，直接以提升硬體的方式對系統做出優化。

　　　　　但本文主要介紹了磁碟壓力的主因是記憶體不足引起的，記憶體不足又很大程度是語句寫的太差，或明顯缺少索引導致。

　　　　　不要讓一個很簡單調優就能解決的問題，升級為要花高價換硬體。

　　　　　不能否認提升硬體效果肯定會有，但是找出系統真正的原因，對症下藥更為重要。

 ----------------------------------------------------------------------------------------------------

注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！

　　引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”

為了方便閱讀給出系列文章的導讀連結：