現在很多使用者被資料庫的慢的問題所困擾，又苦于花錢請一個專業的DBA成本太高。軟體維護人員對資料庫的了解又不是那麼深入，是以導緻問題遲遲不能解決，或隻能暫時解決不能得到根治。開發人員解決資料問題基本又是搜遍百度各種方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。
怎麼樣讓瑣事纏身的程式維護人員，用最快的方式解決資料庫出現的問題？怎麼讓我們程式員的痛苦降低到最小...每天喝喝茶水，看看新聞平安度過一天呢？本系列重要通過
Expert for sqlserver工具講解下資料庫遇到的各種問題的表象及導緻這樣問題的根本原因，讓定位問題更準确，解決問題思路更清晰！！
資料庫的性能好壞，對于最終使用者來說表現為點選的操作是否能夠快速響應，那麼反應到資料庫上就是語句執行時間是否夠短！
對用運維人員資料庫性能的表現，簡單可能看成CPU 、記憶體、磁盤三巨頭名額是否正常，前面講述了CPU和記憶體的基本診斷，為了友善閱讀給出系列文章的導讀連結：
SQL SERVER全面優化-------Expert for SQL Server 診斷系列
本篇我們就講述最後的一位巨頭，看看磁盤能夠看出哪些問題！
廢話不多說，直接開整-----------------------------------------------------------------------------------------
磁盤也許對部分軟體運維人員來說，這東西不歸我管！愛咋咋地，速度慢就換SSD，壞了就再買！但是用在資料庫上的磁盤你怎麼能判斷出是，磁盤的問題？不是你資料庫其他問題導緻的？磁盤壞了...一般的維護人員就哭了。
磁盤配置的建議
這裡的配置建議主要針對資料庫的磁盤使用，首先我們先明确下實體磁盤和邏輯磁盤的概念。
實體硬碟是硬體實體，即安裝在電腦機箱内的硬碟；
邏輯硬碟是指人為在實體上劃出分區以友善存取，管理裡面的檔案。 注：當你感覺到磁盤有壓力，并且想用另一塊磁盤幫助分擔這個壓力時，你需要添加的是實體磁盤而不是邏輯磁盤。
SQL SERVER中主要存儲在磁盤，并且主要影響你系統的檔案主要有：資料檔案、日志檔案、tempDB資料檔案（tempDB日志可以忽略），很多使用者的一台伺服器上運作這多個資料庫或多執行個體，那麼針對你的現有資料庫規劃好磁盤配置設定是第一課！
規劃磁盤配置設定的好處：假設你有兩個資料庫，業務操作都很繁忙，且讀/寫量都很大對磁盤的壓力都很大，那麼你自然會想到把他們分散到不同的磁盤上，這樣每個庫針對自己的磁盤讀/寫，不會互相影響且壓力相當于原來的1/2，進而可以提升磁盤操作的響應時間。
資料庫磁盤該怎麼劃分？ 不同系統不同環境可能都不相同，下面給出一些簡單建議:
- 按照檔案類型劃分：資料檔案、日志檔案、tempDB檔案、備份檔案，分别放在一個實體磁盤（3塊實體磁盤）
- 按照資料庫劃分：不同的業務資料庫（壓力大的）分别放在一個實體磁盤，tempDB和備份檔案各一個實體磁盤。
上面的兩種分法是基本的劃分方式，但是根據系統壓力系統配置，均有不同情況。
當你的資料庫壓力較小，或磁盤資源緊張可以做适當的合并。當你的資料庫特别大，并且有多個檔案組，也可以選擇把檔案組更進一步細分。
類似于做了分區表，不同分區放在不同磁盤上，當需要多個分區資料時，可以利用IO并行提升效率。
如何區分你的磁盤是實體盤還是邏輯盤？
此例中C:H:是同一實體盤，Y:G:是同一實體盤，Y: 和 Z:都是單分區的實體盤。這次中共有4個實體磁盤
此例中每個都是一個單獨的實體磁盤
注：磁盤資訊可以通過系統資訊（運作-msinfo32）或通過性能計數器等等手段檢視。
下面看一個檔案劃分的例子: （例子使用上面C:D:E:F:J都是單獨實體磁盤）
tempDB放在F盤
資料檔案（.mdf）放在D盤，日志檔案(.ldf)放在E盤
磁盤壓力的診斷和分析
磁盤的壓力分析，主要使用下面幾個性能計數器 （針對單獨的實體盤，每個實體磁盤都會有一組）：
- Avg. Disk Read Queue Length 讀隊列（越小越好，理想值 2 以下，隊列越高說明一個操作的響應時間越長）
- Avg. Disk Write Queue Length 寫隊列（越小越好，理想值 2 以下，隊列越高說明一個操作的響應時間越長）
- Avg. Disk sec/Read
- Avg. Disk sec/Write
- Disk Read Bytes/sec
- Disk Write Bytes/sec
注：正常判斷系統磁盤壓力，通過讀寫隊列即可判斷，後面4個主要用于磁盤是否自身性能存在問題，本文不介紹。
首先有哪些情況會對磁盤造成壓力？
- 記憶體不足導緻需要頻繁和磁盤互動 （一般為主因）
- 經常有大量冷資料需要從磁盤讀取，或經常有大批量髒頁一次寫入（checkpoint觸發）
- 磁盤讀寫速度，不能滿足業務需要
為什麼記憶體不足會導緻磁盤壓力大？
上一篇介紹了，記憶體這三個計數器是如何關聯的？
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）
借用上一篇
Expert 診斷優化系列------------------記憶體不夠用麼？三小時一次記憶體的例子，我們看看磁盤是什麼樣的表現
這内規律波動，記憶體壓力很有規律，記憶體壓力不過多介紹請參見上一篇。我們看看磁盤對應時間點的計數器是什麼樣子的？ 你能想想到麼？
是不是規律很強？這個例子展示了磁盤壓力和記憶體的關聯，也說明當你看到磁盤隊列很高的時候，不要輕易定位磁盤的問題，先看看目前系統記憶體是怎麼樣的狀态吧。
借助上一篇第二個，記憶體嚴重不足的例子：
我們來看看這麼大記憶體的壓力下，磁盤是什麼狀态，我想已經不用我說過多了。
高能預警：隊列高可能，不那麼直覺的說明啥，下面我們來看一下這麼高隊列下的響應時間。每次和磁盤互動就要有1秒以上的磁盤響應時間（正常幾毫秒），那麼一個語句多次互動會是什麼樣的效果？
----------------------------------------------------------------------------------
至此我們了解到了，系統磁盤隊列高的根本原因是由于記憶體不足導緻的，那麼我們抛開記憶體壓力不談，遇到上面的情況我們怎麼緩解磁盤壓力呢？？？
那就是前面提到的用多塊磁盤分擔這個壓力或選用速度更快的。
看一下這個系統的磁盤及資料庫檔案分布
可以看到這個伺服器隻配置了一塊實體磁盤
資料庫1
資料庫2
tempDB
2個業務頻繁的大資料庫，資料檔案、日志檔案和系統tempDB都在同一個磁盤上！
如果有其他實體磁盤可以分攤壓力，讀寫隊列會有降低，讀寫響應時間也會大幅縮短，但我們不能忽略根本原因是記憶體的超大壓力！
最佳的優化效果，當然即做記憶體做優化（請參見上一篇
） 又按照最佳的實踐把檔案分散到多個磁盤分擔壓力。
-----------------------------------------------------------------------------------------------------
總結：現在硬體成本越來越低，很多使用者都采用SSD或進階存儲等，直接以提升硬體的方式對系統做出優化。
但本文主要介紹了磁盤壓力的主因是記憶體不足引起的，記憶體不足又很大程度是語句寫的太差，或明顯缺少索引導緻。
不要讓一個很簡單調優就能解決的問題，更新為要花高價換硬體。
不能否認提升硬體效果肯定會有，但是找出系統真正的原因，對症下藥更為重要。
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”
為了友善閱讀給出系列文章的導讀連結：