前言
首先任何一個數據庫不是獨立存在的，也不是憑空想象決定出來的。
數據庫的架構離不開應用的場景。所以，為了解決某些深入的問題，首先你得掌握數據庫的原理與架構。原理掌握得越深入，越能幫助你定位復雜與隱藏的問題。
其次，DBA不能只局限於數據庫本身。因為問題的來源，很多時候都來自用戶表象（比如說用戶反映查詢某個東西很慢）。這個表象 問題，可能來自從應用到數據庫，到OS，存儲等方面。或者是網絡鏈路的任一環節等。
最后，DBA常需要關注的層面，除了應用，更重要的還有OS硬件相關的層面。如內存，CPU，磁盤等。
背景知識：數據庫經典三層架構圖
背景知識：MySQL體系架構
圖1即為MySQL的邏輯架構圖，可以簡單地歸結為四層結構：
第一層為客戶端連接層，主要是做一些連接處理、權限認證、安全連接等處理。
第二層為服務管理層，實現了諸如SQL接口、解析、優化、緩存以及備份恢復、復制等核心功能。
第三層為插件存儲引擎層，這是MySQL區別於其它數據庫系統如ORACLE、MSSQL SERVER最重要的一點，MySQL中數據的存儲和提取最終是由存儲引擎來實現的，不同的存儲引擎存取數據的方式不一樣，它們通過統一的API與服務層進行通信。
第四層為數據存儲層，確切地說它不屬於MySQL系統，只是MySQL生成的數據、日志等文件最終是要保存在磁盤文件系統中的。
背景知識：MySQL體系架構
背景知識：MySQL內核架構
MySQL定位問題關注方面
數據庫層面
- MySQL Slow log （80%的問題，都來自SQL應用的問題）
- Mysql error log
- MySQL統計狀態信息
- Show global status;
- Show engine innodb status\G
- Show full processlist;
- Show master status
- Show slave status
OS層面
- 內存，磁盤，IO，網絡等
- free, vmstat, iostat, top, sar -n DEV, demesg, perf等
有圖表的情況下，盡量多通過圖表方式來查看指標變化趨勢。所謂一圖頂千言。
MySQL定位問題思路與方法
排除法
- 排除應用問題（查看slow log）
- 排除OS問題（查看OS各類輸出，圖表等）
- 排除數據庫本身問題（查看數據庫，狀態，延時等）
搜索路徑（知識爆炸的時代，誰也不可能記住所有的問題）
- 百度
- 谷歌
- Oracle Support知識庫 https://support.oracle.com/portal/
慢SQL問題定位方法
- Explain
- Show Profile
- mysqldumpslow
MySQL性能優化關注點
SQL及索引優化
- 根據需求寫出良好的SQL，並創建有效的索引，實現某一種需求可以多種寫法，這時候我們就要選擇一種效率最高的寫法。這個時候就要了解sql優化
- 數據庫表結構優化
- 根據數據庫的范式，設計表結構，表結構設計的好直接關系到寫SQL語句。
系統配置優化
- 大多數運行在Linux機器上，如tcp連接數的限制、打開文件數的限制、安全性的限制，因此我們要對這些配置進行相應的優化。
硬件配置優化
- 選擇適合數據庫服務的cpu，更快的IO，更高的內存。
- 但不意味着越強越好。因為我們總是在成本與收益之間權衡。配置過低，性能無法滿足要求。配置太高，造成浪費。
- 我們應該在選擇合理的配置，並預留部分資源以應對突發流量。
注：通過下圖可以看出，該金字塔中，優化的成本從下而上逐漸增高，而優化的效果會逐漸降低。
性能優化的原則
- 優化永遠不會結束（也即不需要做無畏的優化）
- 2/8理論，短板理論（改善20%的短板，提升80%的性能）
所謂性能優化，在大部分情況而言，就是找到導致性能的瓶頸所在，並加以解決。
案例分享
某部門系統從ORACLE數據庫遷移到MySQL，碰到了嚴重的性能問題。實測TPS不足ORACLE DB的30%。
我的性能優化過程步驟：
- 前期現場查看數據表定義，配置文件等。
- 發現問題表沒有使用主鍵，insert values一條一條插入導致速度很慢，配置文件參數不合適(innodb buffer pool, redo log, io_capacity等）等問題。
- 現場測試，性能還是有問題（表象為Mysql服務器IO，CPU負載都很小）
采用排除法
-
- 用sysbench壓測沒有問題，排除硬件OS問題
- 數據庫查詢狀態正常，沒有問題
- 剩下，只能是應用問題。
查看網絡流量，抓取數據包，發現應用流量很小。
代碼排查，oracle以前用sequence。MySQL不支持，應用代碼實現生成ID。
這段代碼有問題，出現鎖爭用，導致應用流量一直很小。