現在很多使用者被資料庫的慢的問題所困擾，又苦于花錢請一個專業的DBA成本太高。軟體維護人員對資料庫的了解又不是那麼深入，是以導緻問題遲遲不能解決，或隻能暫時解決不能得到根治。開發人員解決資料問題基本又是搜遍百度各種方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。
怎麼樣讓瑣事纏身的程式維護人員，用最快的方式解決資料庫出現的問題？怎麼讓我們程式員的痛苦降低到最小...每天喝喝茶水，看看新聞平安度過一天呢？本系列重要通過
Expert for sqlserver工具講解下資料庫遇到的各種問題的表象及導緻這樣問題的根本原因，讓定位問題更準确，解決問題思路更清晰！！
資料庫的性能好壞，對于最終使用者來說表現為點選的操作是否能夠快速響應，那麼反應到資料庫上就是語句執行時間是否夠短！
對用運維人員資料庫性能的表現，簡單可能看成CPU 、記憶體、磁盤三巨頭名額是否正常，上一篇講述了CPU的基本診斷
Expert 診斷優化系列------------------你的CPU高麼？
本篇我們就從記憶體下手，看看記憶體能夠看出哪些問題！
廢話不多說，直接開整-----------------------------------------------------------------------------------------
首先說明一個誤區，你是否被這樣的畫面所震驚？
我的伺服器記憶體滿了，就是這個導緻我資料庫慢！我的程式報錯也是因為這個，什麼都因為記憶體滿了！！ 趕緊加記憶體吧~
這個答案是大寫的 “不一定”，SQL SERVER是一個很愛記憶體的家夥，他會緩存你的資料，執行計劃，連接配接資訊等等，是以出現這個現象是很正常的，不要輕易下結論，除非你經過仔細的研究和分析！
那麼怎麼去分析到底是不是記憶體不足導緻的問題呢？ 下面我們來說說！
主要用到的性能計數器（不知道什麼是性能計數器的，請自行百度）
- Page life expectancy （資料庫計數器：主要顯示不被使用的頁，将在緩存中停留的秒數 ）
- Lazy writes/sec （資料庫計數器：惰性寫入器會在記憶體有壓力且有新的記憶體需求時觸發，成批的重新整理“老化的緩沖區”）
- Page Reads/sec，Page Writes/sec （這裡使用資料庫級别計數器：當需要讀取或寫入的頁不在記憶體中，需要到磁盤中讀取時計數）
- Target Server Memory (KB) （SQL server能夠使用的記憶體總量）
- Total Server Memory (KB) （SQL SERVER使用的記憶體總量，這裡指BUFFER POOL的大小）
- Available MBytes （系統系數器：主要顯示系統還有多少可用記憶體）
注：Target Server Memory (KB) - Total Server Memory (KB) 約等于SQL SERVER還可以使用的記憶體數。
Available MBytes 主要顯示系統中還多少空閑記憶體 （如果這個值較大，而SQL SERVER還可以使用的記憶體數為0或者較小，可以适當的調大max server memory（最大記憶體，稍後介紹））
這裡不再細說這三個計數器，我們主要通過前三個計數的關聯來判斷系統的記憶體是否真的存在壓力！！！
首先介紹一下，這三個計數器是如何關聯的？
概念出發：Page life expectancy 不被使用的頁在緩存中停留的秒數，如果低說明記憶體壓力
Page Reads/sec 所要讀的資料不在記憶體中需要實體讀取
Lazy writes/sec 記憶體壓力時成批的重新整理老化緩沖區
當一個操作需要大量讀取資料，且資料頁不在緩存中 ——》 那麼需要大量從磁盤讀取冷資料放入緩存（Page Reads/sec 升高） ——》緩存有明顯壓力的時候Lazy writes/sec就會觸發（Lazy writes/sec升高），大批量的将老化的資料或緩存計劃等刷出緩存 ——》資料被清出緩存，那麼頁生命周期就會下降（Page life expectancy）
Page Reads/sec
Lazy writes/sec
Page life expectancy
高能預警：當你看到自己的計數器是這個樣子的時候，你給的出結論不應該單單是，我記憶體有壓力！
這個例子不光為了說明三計數器是關聯，而且也可以看出規律，那就是每三小時一次明顯的記憶體壓力。正如第一篇CPU文章的介紹，這種規律性的表象，作為系統的維護人員，一定要仔細想想什麼操作導緻的問題？不要因為一個簡單的配置問題而拖慢了整個系統！
我通過對問題時間點的語句分析發現，這個系統每三小時進行一次日志備份，正常的日志備份不會導緻這樣的現象，但如果在日志備份的時候加上CHECKDB呢？
這就是所說的不要因為一個小的失誤而影響整個系統！
--------------------------------------------------------------------------------------------
系統記憶體不足的表象
下面展示一個記憶體壓力的伺服器這三個計數器的表象：
Lazy writes/sec
Page life expectancy 頁生命周期
這幾個計數器反應出的問題絕對是系統記憶體嚴重不足，計數器雙高一低。那麼當我們知道系統記憶體不足的時候應該怎麼辦呢？加記憶體麼？
不要急，下面我們說說如何讓你的系統節省記憶體，也許做過這一輪優化，你的系統記憶體就夠用了！ 你沒聽錯，就是-----優化！
優化-----讓你的記憶體無壓力
你要給你的系統設定最大記憶體max server memory
問：我系統記憶體本來就不夠為什麼還要設定使用上限？我這伺服器就給資料庫用還用設定？
答：資料庫是運作在windows 上的應用，他和notepad對于作業系統來說本質上沒差別，那麼這就好比君（作業系統）與 臣（資料庫）的關系。
而SQL SERVER是一個很喜歡記憶體的應用，是以很可能吃掉大量記憶體導緻windows系統沒有足夠記憶體使用，，那麼這時候君臣關系就展現的淋漓盡緻了，君(windows) 要臣（SQL SERVER）死（釋放記憶體）臣不得不死呀...這個釋放在一定程度上可不是單單讓windows夠用了，很可能導緻SQL記憶體陡降，以緻SQL 短時間假死（操作無響應）。是以為了你資料庫的穩定性，這個最大上限一定要設定。
記憶體設定推薦：
一般我比較推薦如果記憶體較小作業系統預留3G-4G ，如果記憶體大256或512以上在資料庫記憶體無壓力時預留5%給作業系統，剩下給SQL SERVER ，如果伺服器還有其他應用還要在SQL 中減掉應用所占的記憶體。
如果記憶體比較小且資料庫記憶體壓力大，則可以通過前面講述的Available MBytes 的判斷結果适量給系統預留記憶體。
注意：最大記憶體的設定機關為 MB
語句的優化，讓語句消耗記憶體更少！
語句優化系列請關注後續文章，這裡隻針對降低記憶體
降低記憶體對語句優化主要集中在幾個方面：
- 是否缺失索引？
- 消耗記憶體的操作是否可以消除（如排序）
- 降低語句複雜性，讓優化器能選用最佳計劃
語句消耗記憶體主要展現在大量的讀取，或者有排序等操作。限于篇幅這裡隻做簡單的例子，詳細的語句優化請關注後續文章。
所謂的讀，寫簡單了解就是在語句執行時所需要用到的資料頁數，需要的越多就需要越大的記憶體來緩存這些資料頁。如果需要的頁不在記憶體中還需要從磁盤讀取 （磁盤讀取就是為什麼Page Reads/sec 會高）
簡單的一個加索引降低邏輯讀的例子~
語句使用了一個整個表掃描的計劃，執行了 19秒，邏輯讀取143800次，預讀137236 （磁盤上讀取），消耗了40KB 的記憶體 ，并且明确提示出缺少索引！
那麼我們加上提示缺少的索引，再次執行
加上索引的語句執行不到1秒 邏輯讀降低到13次，記憶體消耗已經可以忽略不計。這就是索引對語句的重要性！單條語句如此，你的系統中到底有多少這樣的語句呢？
再來看一個寫法修改的例子 ：
隻是簡單的改了下語句的寫法時間有7秒變成1秒，記憶體消耗從300+MB 變成 1MB
這兩個例子，告訴我們也許系統中簡簡單單做一些調整，記憶體的壓力就會明顯降低或者變得非常充足，是以在你下了一個需要購買記憶體的決定前，是否針對系統的語句進行過調優？
-----------------------------------------------------------------------------------------------------
對于記憶體性能計數器的閥值簡單說明
Page life expectancy 計數器這個時間要高于多少才算正常呢？
答：很多資料上多這個值都有誤解，說是300S，300S是在十多年前的一個參考值，是基于當時的伺服器記憶體受到4GB記憶體的限制的影響得到的，
目前伺服器記憶體動辄超過100GB的情況下，用同樣的标準，顯然是不夠準确的，這個值的計算是跟具體的伺服器記憶體配置有關的，一個可供參考的标準算法是 Max Buffer Pool(GB)/4*300(S)
為什麼這裡缺少了一個 Buffer Cache hit ratio 計數器？
很多材料上都介紹其門檻值是90%，95%之類的參考值，其實都是錯誤的，
其實真正觀察過的人，早就會發現，從PLE和Buffer hit ratio得出根本不一緻的結論。
詳細說明請參見：wy123的部落格
Sql Server 記憶體相關計數器以及記憶體壓力診斷
Buffer cache hit ratio性能計數器真的可以作為記憶體瓶頸的判斷名額嗎？
-----------------------------------------------------------------------------------------------------
總結：記憶體對于資料庫來說是最為重要的依賴之一，記憶體的問題診斷和優化對系統至關重要。
優化語句可以讓你的系統記憶體壓力明顯降低。
語句優化所帶來的效果，在很大程度上會比新增硬體更有效！
作為一個技術人員對于系統問題的定位、分析、調優是最重要的，如果記憶體問題都通過加記憶體來解決，我們的價值何在呢？
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”
為了友善閱讀給出系列文章的導讀連結：