1.1 前言 MySQL對於很多Linux從業者而言，是一個非常棘手的問題，多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要瞭解的就是MySQL的查詢過程，很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式運行而已。 今天給大家 ...
1.1 前言 MySQL對於很多Linux從業者而言，是一個非常棘手的問題，多數情況都是因為對資料庫出現問題的情況和處理思路不清晰。在進行MySQL的優化之前必須要瞭解的就是MySQL的查詢過程，很多的查詢優化工作實際上就是遵循一些原則讓MySQL的優化器能夠按照預想的合理方式運行而已。 今天給大家體驗MySQL的優化實戰，助你高薪之路順暢。
圖 - MySQL查詢過程 1.2 優化的哲學 優化有風險，涉足需謹慎 1.2.1 優化可能帶來的問題
1.2.2 優化的需求
1.2.3 優化由誰參與
在進行資料庫優化時，應由資料庫管理員、業務部門代表、應用程式架構師、應用程式設計人員、應用程式開發人員、硬體及系統管理員、存儲管理員等，業務相關人員共同參與。
1.3 優化思路
1.3.1 優化什麼
在資料庫優化上有兩個主要方面：即安全與性能。
1.3.2 優化的範圍有哪些
存儲、主機和操作系統方面:
應用程式方面:
資料庫優化方面:
說明：不管是在，設計系統，定位問題還是優化，都可以按照這個順序執行。
1.3.3 優化維度
資料庫優化維度有四個:
硬體、系統配置、資料庫表結構、SQL及索引
優化選擇
1.4 優化工具有啥？
1.4.1 資料庫層面
檢查問題常用工具
不常用但好用的工具
1.4.2 資料庫層面問題解決思路
一般應急調優的思路：
針對突然的業務辦理卡頓，無法進行正常的業務處理！需要立馬解決的場景！
常規調優思路： 針對業務周期性的卡頓，例如在每天10-11點業務特別慢，但是還能夠使用，過了這段時間就好了。
1.4.3 系統層面
cpu方面
vmstat、sar top、htop、nmon、mpstat
記憶體
free、ps -aux 、
IO設備（磁碟、網路）
iostat、 ss 、 netstat 、 iptraf、iftop、lsof、
vmstat 命令說明：
iostat命令說明
實例命令： iostat -dk 1 5
iostat -d -k -x 5 （查看設備使用率（%util）和響應時間（await））
1.4.4 系統層面問題解決辦法 你認為到底負載高好，還是低好呢？ 在實際的生產中，一般認為 cpu只要不超過90%都沒什麼問題 。 當然不排除下麵這些特殊情況： 問題一：cpu負載高，IO負載低
問題二：IO負載高，cpu負載低
問題三：IO和cpu負載都很高
硬體不夠了或sql存在問題
1.5 基礎優化
1.5.1 優化思路
定位問題點:
硬體 --> 系統 --> 應用 --> 資料庫 --> 架構（高可用、讀寫分離、分庫分表）
處理方向
明確優化目標、性能和安全的折中、防患未然
1.5.2 硬體優化
主機方面：
cpu的選擇：
記憶體的選擇：
存儲方面：
raid卡：主機raid卡選擇：
網路設備方面：
使用流量支持更高的網路設備（交換機、路由器、網線、網卡、HBA卡）
註意：以上這些規劃應該在初始設計系統時就應該考慮好。
1.5.3 伺服器硬體優化
1.5.4 系統優化
Cpu：
基本不需要調整，在硬體選擇方面下功夫即可。
記憶體：
基本不需要調整，在硬體選擇方面下功夫即可。
SWAP：
MySQL儘量避免使用swap。阿裡雲的伺服器中預設swap為0
IO ：
這個參數決定了Linux是傾向於使用swap，還是傾向於釋放文件系統cache。在記憶體緊張的情況下，數值越低越傾向於釋放文件系統cache。當然，這個參數只能減少使用swap的概率，並不能避免Linux使用swap。
修改MySQL的配置參數innodb_flush_method，開啟O_DIRECT模式。這種情況下，InnoDB的buffer pool會直接繞過文件系統cache來訪問磁碟，但是redo log依舊會使用文件系統cache。值得註意的是，Redo log是覆寫模式的，即使使用了文件系統的cache，也不會占用太多
IO調度策略
1.5.5 系統參數調整
Linux系統內核參數優
用戶限制參數（mysql可以不設置以下配置）
1.5.6 應用優化
業務應用和資料庫應用獨立,防火牆：iptables、selinux等其他無用服務(關閉)：
安裝圖形界面的伺服器不要啟動圖形界面 runlevel 3,另外，思考將來我們的業務是否真的需要MySQL，還是使用其他種類的資料庫。用資料庫的最高境界就是不用資料庫。 1.6 資料庫優化 SQL優化方向： 執行計劃、索引、SQL改寫 架構優化方向： 高可用架構、高性能架構、分庫分表 1.6.1 資料庫參數優化 調整： 實例整體（高級優化，擴展）
連接層（基礎優化）
設置合理的連接客戶和連接方式
SQL層（基礎優化）
query_cache_size： 查詢緩存
OLAP類型資料庫,需要重點加大此記憶體緩存.
但是一般不會超過GB.
對於經常被修改的數據，緩存會立馬失效。
我們可以實用記憶體資料庫（redis、memecache），替代他的功能。
1.6.2 存儲引擎層（innodb基礎優化參數）
在這裡推薦一篇還不錯的sql優化文章：https://www.cnblogs.com/SimpleWu/p/9650343.htm
