史上最全的MySQL高效能優化實戰總結！
1.1 前言
SQL/">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基礎優化引數）
為什麼某些人會一直比你優秀，是因為他本身就很優秀還一直在持續努力變得更優秀，而你是不是還在滿足於現狀內心在竊喜!
歡迎工作一到五年的Java工程師朋友們加入Java架構開發：744677563
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！