00 優化之前我們應該做什麼？
在說給數據庫做性能優化時，我們應該做些什麼呢？
我們在優化之前一定要了解數據庫內部原理嗎？
要去不斷調整數據庫、操作系統的參數呢？
數據庫的性能就只是數據庫的架構決定的，跟應用、開發關係不大嗎？
我們是不是必須遇到了瓶頸要做讀寫分離、分庫分表呢？
NO!
其實，它們可能都是數據庫優化的一部分，但既不是開始，也不是目的，更不是全部。
我們首先要搞懂，爲什麼要做數據庫的優化？
從業務角度出發，是爲了減少用戶響應時間。
從數據庫角度看，是爲了減少數據庫SQL響應時間。
從數據庫的服務器角度來說，是爲了充分使用數據庫服務器物理資源，減少CPU、IO、內存的使用率。
我們在優化之前，一定要給出一個目標。
如
•響應時間變短，優化前數據庫的平均響應時間是500ms，指定優化目標縮減到200ms。•CPU佔用率變少，優化前高峯期使用率70%，優化後變成50%。•IO使用率變低，優化前IO WAIT 30%，優化後10%。•SQL執行時間變短，優化前1000條SQL執行爲3600s，優化後降到200s。
還有其他諸如硬解析率、軟解析率、TPS壓測值，也都可以作爲一個指標。
至於指標到底怎麼定？我們接下來繼續說。
01 做數據庫優化有流程嗎？
我們應該制定一個什麼樣的流程，來做數據庫優化？
或者說，我們做數據庫優化時，應該要經過一個什麼流程呢？
如圖：
1、我們首先應該瞭解待優化的問題；【到底出了什麼問題？】
2、收集系統信息；【哪裏出了問題？】
3、制定優化目標；【得到客戶認可，解決什麼問題？】
4、分析性能問題；【具體的問題在哪裏？什麼原因引起的問題？】
5、制定優化方案；【針對分析出的問題怎麼去解決？】
6、實施優化方案；【誰來實施？怎麼實施？有沒有風險？】
7、判斷是否達到優化目標；【效果怎麼樣？如果不行還需要重新分析問題。】
8、編寫優化報告。【目標達到，我們要編寫優化報告，告訴客戶解決了什麼問題。】
以上，便是我們數據庫優化的一個大體流程。
接下來具體說說怎麼做。
02 信息收集與目標制定
首先，我們要了解待優化的問題。
從哪裏瞭解？用戶、運維、開發人員等等。
我們一般能瞭解到什麼信息？
用戶一般會說應用訪問慢、系統卡、打不開等等。
運維人員會說服務器的硬件資源佔用率高，如CPU很高、內存不夠了等等
開發人員會說接口總是報錯，數據庫響應時間變得很長，TPS、QPS壓不上去。
那麼，這些信息都是真實有效的嗎？
我們在這裏謹記一個守則：凡是“判斷”、“分析”類的信息統統屏蔽，凡是“症狀”、“表現”類的信息細細保留。
why？
因爲別人的“判斷”，特別是來自以上三類人羣的“判斷”，大部分是片面的，很可能會干擾你的思路，甚至會把你帶到溝裏去，讓你對某些問題視而不見，導致做了大半天的無用功。
我們要有一套自己的優化思路。
在瞭解到當前待優化的問題後，我們緊跟着要幹什麼？開始優化嗎？
當然不是。
而是最基本的，來到第二步，收集系統信息。並且儘可能全面地收集系統信息。
我們可以從業務、數據庫、服務器等角度收集系統信息。分類保存，以便後期優化時使用。
然後纔是我們前面章節所說的，制定優化目標。
怎麼制定優化目標？
首先是分析數據庫大概存在的瓶頸，然後是制定明確的優化目標（如業務、數據庫、服務器等多種角度）。
最重要的是，優化前一定要跟客戶溝通好，讓客戶確認本次優化的目標，得到認可。
再接着，就是具體地分析性能問題了。
03 問題分析
問題分析這一塊可以說的內容太多了，所以單獨放了一小節。
首先，我們可以採用自上而下的順序進行分析。
操作系統（CPU、IO、NETWORK）-> 數據庫實例-> 數據庫對象-> SQL
對操作系統我們採用什麼工具呢？我們現在的服務一般都是部署在Linux上的，所以我們一般使用以下這些工具進行檢測。
•SAR•HTOP•NMON•TOP•ETHTOOL•……
那對於數據庫，我們有什麼工具來分析數據庫的等待時間瓶頸呢？
•ORACLE：AWR、STATSPACK、內部視圖、GRID CONTROL、STA、SAA、ADDM•MYSQL：慢日誌、PERCONA TOOLKIT、MEM、內部視圖……•SQLSERVER：SQL PROFILE、內部視圖……•POSTGERS：pg_stat_statements、SQL trace……•達夢：AWR、內部視圖、監控工具、SQL trace……
在使用上面的工具對操作系統、數據庫進行信息收集、初步分析後，我們緊接着就要根據找到的瓶頸進行深入分析。
從哪些方面分析？
•操作系統參數是否配置合理？•數據庫參數是否合理？•索引設計合理嗎？•數據庫有沒有bug？排除下•捕獲主要的問題SQL，對其進行深入分析•硬件資源是不是不足了？•數據庫的選型是否恰當？•數據庫表設計是不是合理？•是不是業務流程的設計存在問題導致的數據庫性能問題？
從實際的優化經驗來說，大部分的數據庫性能問題都是由問題SQL導致的。而問題SQL的大部分起因都是索引設計不合理，甚至沒有索引。
04 制定及實施優化方案
在找到問題原因後，我們怎麼去制定並實施優化方案呢？
•數據庫架構調優•數據庫表結構優化設計•操作系統內核參數優化•數據庫參數優化•添加或刪除索引•改寫SQL語句•調整應用流程•採用數據庫高級特性•升級硬件•……
這些都是優化的方案，那我們怎麼選擇呢？
歸根到底，還是要根據我們問題分析的結果去制定。一個完整的優化方案應該包含如下內容：
•1、背景；•2、問題現象；•3、分析過程及結論；•4、優化建議；•5、實施計劃及風險。
我們例舉一個案例，這個案例是oracle的。
1、背景
運維人員反應系統報表出不出來。
2、問題現象
XX系統經常夜裏12點就刷不出來了，要等很長時間。
3、分析過程及結論
從整體ASH報告分析，數據庫性能壓力一般，但是特定時間的數據庫問題比較明顯，一般集中在晚上20:00-凌晨1:00左右。
某些SQL執行時間到達1000s以上。這類SQL必須優化。
4、優化建議
1）從AWR報告抓取問題SQL，提交開發修改。2）對log_XXX_detail等類似大表進行修改，調整字段類型，並對錶進行分析。
5、實施計劃及風險
基本無風險；但需應用配合，無需重啓數據庫。
在實施方案的時候，我們需要注意什麼？
1、數據庫實例優化方案應由運維人員及DBA實施;
2、SQL優化方案由開發人員修改應用措施；
3、任何類型的實施在操作前都需要做好計劃及回滾方案。
05 編寫優化報告
我們在優化完畢了，這個事情就結束了嗎？
不！
我們還要對整體優化做出總結。
why？
因爲我們要體現出優化的價值，並且爲下次優化打好基礎。
我們的報告要能明確體現出優化的效果。
優化報告怎麼寫？一般注意以下幾個要素:
•1、數據庫優化背景；•2、索引重建優化前後對比；•3、CPU使用率；•4、磁盤基線；•5、鎖使用情況；•6、其他未盡之說明。
爲什麼要寫優化報告？
一言以蔽之，這就是你工作中的業績報告。如果幹了活不被人知，不爲人曉，那就是個傻把式。
升職加薪跟你有什麼關係呢？
接下來舉幾個簡單的優化報告的案例。
實例1：Oracle
某項目因IO資源不足導致數據庫性能低下
數據庫現象：CPU大量消耗
應用系統現象：大量IO等待、陣列IO不足
操作：購買新陣列、遷移數據庫
效果：問題基本緩解
實例2：SQLSERVER
某項目數據庫計算時間超過10小時
數據庫現象：CPU和IO佔用率較低
應用現象：系統基本空閒
操作：重新改寫計算邏輯
效果：效率提升10倍以上
實例3：MYSQL
某項目數據庫經常中斷
數據庫現象：主主模式經常出現數據不一致
應用系統現象：無明顯特徵
操作：調整架構爲MHA模式
效果：數據庫故障現象充分緩解
06 總結
梳理下本章我們學習的內容：
1、瞭解優化流程，收集問題信息。
2、優化流程的重點是問題分析這一步，要能通過科學的方法、便捷的工具，敏銳地發現系統瓶頸或者故障點；
3、優化可以從多個角度考慮，思路要開闊；
4、優化有大致的流程，但，是沒有固定方法的。
07 後記
以上這一篇內容是數據庫優化系列文章一篇，內容基本上是我在前公司的《數據庫訓練營》學習到的內容。
我覺得我遇到的這位老師說的很有道理。
其實問題並不可怕，怕的是不知道問題在哪？
問題也不難解決，難的是知道解決問題的方向。
僅以此希望跟大家分享。
後續的文章也會以oracle、mysql爲主，從理論到實踐，從方法到實戰，來繼續我們的數據庫優化之路。
我的小專欄：https://xiaozhuanlan.com/topic/1273960485
本文分享自微信公衆號 - 架構師之殤（ysistrue）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。