MySQL優化基礎

　　首先簡單一幅圖描述一下MySQL的各組件之間如何協同工做的架構圖：

　　第一層：客戶端層，並不是MySQL所獨有，諸如：鏈接處理、受權認證、安全等功能均在這一層處理。

　　第二層：MySQL大多數核心服務均在中間這一層，包括查詢解析、分析、優化、緩存、內置函數(好比：時間、數學、加密等函數)。全部的跨存儲引擎的功能也在這一層實現：存儲過程、觸發器、視圖等。

 　　第三層：最下層爲存儲引擎，其負責MySQL中的數據存儲和提取。和Linux下的文件系統相似，每種存儲引擎都有其優點和劣勢。中間的服務層經過API與存儲引擎通訊，這些API接口屏蔽了不一樣存儲引擎間的差別。

優化內容：

　　在數據庫優化上有兩個主要方面：即安全（數據可持續性）與性能（數據的高性能訪問）。

　　優化方向：

　　　　①存儲、主機、操做系統方面：主機架構穩定性、I/O規劃及配置、Swap交換分區、OS內核參數和網絡問題

　　　　②應用程序方面：應用程序穩定性、SQL語句性能、串行訪問資源

　　　　③數據優化：內存、數據庫結構（物理&邏輯）、實例配置

 　　優化維度：硬件、系統配置、數據庫表結構、SQL及索引：

  

可選優化工具：

　　

　　

數據庫層面調優：

　　通常的應急調優思路：針對忽然的業務辦理卡頓，沒法進行正常的業務處理！須要立馬解決的場景！

　　①show processlist

　　②explain select id ,name from stu where name='clsn'; # ALL id name age sex

　　　　select id,name from stu where id=2-1 函數 結果集>30;

　　　　show index from table;

　　③經過執行計劃判斷，索引問題（有沒有、合不合理）或者語句自己問題

　　④show status like '%lock%'; # 查詢鎖狀態

　　　　kill SESSION_ID; # 殺掉有問題的session

　　常規調優思路：針對業務週期性的卡頓，例如在天天10-11點業務特別慢，可是還可以使用，過了這段時間就行了。

　　①查看slowlog，分析slowlog，分析出查詢慢的語句。

　　②按照必定優先級，進行一個一個的排查全部慢語句。

　　③分析top sql，進行explain調試，查看語句執行時間。

　　④調整索引或語句自己。

系統層面調優：

　　①cpu方面：vmstat、sar top、htop、nmon、mpstat

　　②內存：free 、ps -aux 

　　③IO設備（磁盤、網絡）：iostat 、 ss 、 netstat 、 iptraf、iftop、lsof

　　④vmstat 命令說明：

　　　　Procs：r顯示有多少進程正在等待CPU時間。b顯示處於不可中斷的休眠的進程數量。在等待I/O

　　　　Memory：swpd顯示被交換到磁盤的數據塊的數量。未被使用的數據塊，用戶緩衝數據塊，用於操做系統的數據塊的數量

　　　　Swap：操做系統每秒從磁盤上交換到內存和從內存交換到磁盤的數據塊的數量。s1和s0最好是0

　　　　Io：每秒從設備中讀入b1的寫入到設備b0的數據塊的數量。反映了磁盤I/O

　　　　System：顯示了每秒發生中斷的數量(in)和上下文交換(cs)的數量

　　　　Cpu：顯示用於運行用戶代碼，系統代碼，空閒，等待I/O的CPU時間

　　⑤iostat命令說明：實例命令： iostat -dk 1 5

　　　　iostat -d -k -x 5 （查看設備使用率（%util）和響應時間（await））　　

　　　　tps：該設備每秒的傳輸次數。「一次傳輸」意思是「一次I/O請求」。多個邏輯請求可能會被合併爲「一次I/O請求」。

　　　　iops ：硬件出廠的時候，廠家定義的一個每秒最大的IO次數,"一次傳輸"請求的大小是未知的。

　　　　kB_read/s：每秒從設備（drive expressed）讀取的數據量；

　　　　KB_wrtn/s：每秒向設備（drive expressed）寫入的數據量；

　　　　kB_read：讀取的總數據量；

　　　　kB_wrtn：寫入的總數量數據量；這些單位都爲Kilobytes。

　　⑥系統層面問題排除參考：

　　　　問題一：cpu負載高，IO負載低：

• • 內存不夠
  • 磁盤性能差
  • SQL問題 ------>去數據庫層，進一步排查sql問題
  • IO出問題了（磁盤到臨界了、raid設計很差、raid降級、鎖、在單位時間內tps太高）
  • tps太高: 大量的小數據IO、大量的全表掃描

　　　　問題二：IO負載高，cpu負載低

• • 大量小的IO 寫操做：

  • autocommit ，產生大量小IO

  • IO/PS,磁盤的一個定值，硬件出廠的時候，廠家定義的一個每秒最大的IO次數。

  • 大量大的IO 寫操做

  • SQL問題問題三：IO和cpu負載都很高

　　　　問題三：IO和cpu負載都很高：硬件不夠了或sql存在問題

 

 

具體優化參考：

硬件優化：

　　一、主機方面：

• 根據數據庫類型，主機CPU選擇、內存容量選擇、磁盤選擇

• 平衡內存和磁盤資源

• 隨機的I/O和順序的I/O

• 主機 RAID卡的BBU(Battery Backup Unit)關閉

　　二、cpu的選擇：

• cpu的兩個關鍵因素：核數、主頻

• 根據不一樣的業務類型進行選擇：

• cpu密集型：計算比較多，OLTP 主頻很高的cpu、核數還要多

• IO密集型：查詢比較，OLAP 核數要多，主頻不必定高的

　　三、內存選擇：

• OLAP類型數據庫，須要更多內存，和數據獲取量級有關。

• OLTP類型數據通常內存是cpu核心數量的2倍到4倍，沒有最佳實踐。

　　四、存儲方面：

• 根據存儲數據種類的不一樣，選擇不一樣的存儲設備

• 配置合理的RAID級別(raid五、raid十、熱備盤)

 

• 對與操做系統來說，不須要太特殊的選擇，最好作好冗餘（raid1）（ssd、sas 、sata）

 

　　五、raid卡：主機raid卡選擇：

• 實現操做系統磁盤的冗餘（raid1）

• 平衡內存和磁盤資源

• 隨機的I/O和順序的I/O

• 主機 RAID卡的BBU(Battery Backup Unit)要關閉。

　　六、網絡方面：使用流量支持更高的網絡設備（交換機、路由器、網線、網卡、HBA卡）

系統參數調整：

　　Linux系統內核參數優化：

　　

　用戶限制參數（mysql能夠不設置如下配置）：

　　

數據庫優化：

　　SQL優化方向：執行計劃、索引、SQL改寫 

 　　架構優化方向：高可用架構、高性能架構、分庫分表

　　①實例總體（高級優化，擴展）

　　

　　②鏈接層（基礎優化）：設置合理的鏈接客戶和鏈接方式

 　　

　　③SQL層（基礎優化）

• query_cache_size： 查詢緩存

• OLAP類型數據庫,須要重點加大此內存緩存.

• 可是通常不會超過GB.

• 對於常常被修改的數據，緩存會立馬失效。

• 咱們能夠實用內存數據庫（redis、memecache），替代他的功能。

　　④存儲引擎層（innodb基礎優化參數）