【Java學習筆記（一百零二）】之 MYSQL效能優化與查詢優化
本文章由公號【開發小鴿】釋出！歡迎關注！！！
老規矩–妹妹鎮樓：
一． MySQL效能優化
（一） 優化的風險
優化不是對一個環境進行的，而是對一個複雜的已投產系統進行的，存在一定的風險，當優化了一個問題後，另一個問題可能就會出現，因此要控制調優帶來的問題在可接受的範圍內。
（二） 優化的需求
由於優化存在一定的風險，因此不能單純為了優化而優化，要根據業務的需求來優化，重點是保證穩定性和業務的可持續性，這兩點比效能更加重要。
（三） 優化的四個維度
1. 優化的方向
資料庫優化有兩個主要方向：安全與效能。從安全上看是要保障資料的安全性，從效能上看，是要保證資料的高效能訪問。
2. 優化的維度
資料庫的優化可以從四個維度進行：
硬體 ： CPU，記憶體，儲存，網路裝置
系統配置： 伺服器系統，資料庫服務引數
資料庫表結構： 高可用，分庫分表，讀寫分離，儲存引擎，表設計
Sql及索引： sql語句，索引的使用
從優化的成本來分析： 硬體 > 系統配置 > 資料庫表結構 > SQL及索引；
從優化的效果來分析： 硬體 < 系統配置 < 資料庫表結構 < SQL即索引；
（四） 優化的工具
1. mysqladmin
mysql客戶端，可進行管理操作
2. mysqlshow
檢視shell命令
3. show [SESSION | GLOBAL] variables
檢視資料庫引數資訊
4. show [SESSION | GLOBAL] STATUS
檢視資料庫的狀態資訊
5. SHOW ENGINE INNODB STATUS Innodb
檢視引擎的所有狀態
6. information schema
獲取元資料的方法
7. SHOW PROCESSLIST
檢視當前所有連線session的狀態
8. explain
檢視查詢語句的執行計劃
9. how index
查看錶的索引資訊
10. slow-log
記錄慢查詢語句
11. mysqldumpslow
分析slowlog檔案
12. Zabbix
監控主機，系統，資料庫（部署zabbix監控平臺）
13. mysqlslap
分析慢日誌
14. sysbench
壓力測試工具
15. workbench
管理，備份，監控，分析，優化工具
16. mysql profiling
統計資料庫整體狀態工具
17， Performance Shema mysql
效能狀態統計的資料
（五） 資料庫優化思路
資料庫調優時不需要進行全面，大範圍的調優，一般只需要在資料庫層面優化即可。
1. 應急調優的思路
當業務突然卡頓，無法正常執行時，需要立刻解決，思路如下：
（1） show processlist(檢視連結session狀態)
（2） explain(分析查詢計劃)，show index from table(分析索引)
（3） 通過執行計劃判斷，索引問題（有沒有，是否合理）或者語句本身問題
（4） show status like “%lock%” ，查詢鎖狀態
（5） SESSION_ID，殺掉有問題的session
2. 常規調優的思路
對於業務週期性的卡頓，但是不影響正常的使用，用以下的思路解決：
（1） 檢視slowlog, 分析slowlog, 分析出查詢慢的語句
（2） 按照一定優先順序，排查所有的慢語句
（3） 分析top sql ，進行explain除錯，檢視語句執行時間
（4） 調整索引或語句本身
二． 查詢優化
（一） MySQL查詢流程
由於資料庫的讀寫操作比例是10:1，因此sql優化主要是解決查詢的優化問題。下面是查詢的執行路徑：
-
客戶端將查詢sql語句傳送到伺服器中；
-
伺服器檢查查詢快取中是否有該sql語句，如果有則直接返回結果，否則進入下一步；
-
伺服器通過關鍵字解析sql語句，通過語法解析生成解析樹，解析器使用Mysql語法規則驗證和解析查詢，再經過前處理器生成新的解析樹；
-
解析樹被校驗合法後，經過查詢優化器優化轉成查詢計劃，一條語句有很多種執行方式，最後都會返回相同的結果。優化器的作用就是找到這其中最好的執行計劃；
-
查詢執行引擎根據執行計劃完成整個查詢操作，最常使用的是MyISAM引擎和InnoDB引擎。
-
伺服器將查詢結果傳送回客戶端；
（二） 查詢優化
sql是開發者與資料庫的互動手段，因此SQL調優是花費最多時間的，常見的分析手段有慢查詢日誌，EXPLAIN分析查詢，通過定位分析效能的瓶頸，才能夠更好地優化資料庫系統的效能。
1. 慢查詢
（1） 開啟慢查詢日誌
在配置檔案my.cnf或者my.ini中在【mysqld】一行下面加入兩個配置引數：
log-slow-queries=/data/mysqldata/slow-query.log
long_query_time=5
上面是慢查詢日誌的存放位置，一般這個目錄要有mysql的執行賬號的可寫許可權，該目錄設定為mysql的資料存放位置。下面是慢查詢的閾值，只有超過這個時間才是慢查詢，可以記錄在慢查詢日誌中。
（2） 慢查詢分析
通過開啟log檔案檢視哪些SQL語句執行效率低，如果日誌內容過多，可以使用mysqldumpslow工具對慢查詢日誌進行分類彙總，顯示彙總後的摘要結果。
進入log日誌的存放目錄，執行：
mysqldumpslow slow-query.log
該命令有一些引數，如下所示：
-s : 表示按照什麼方式排序，c，t，l，r分別表示按照記錄次數，時間，查詢時間，返回的記錄數排序；ac, at, al, ar, 表示相應的倒序。
-t n： 表示返回前面n條資料
-g: 後面可寫正則匹配模式，大小寫不敏感
由於開啟慢查詢日誌會佔用CPU資源，因此我們可以階段性地開啟慢查詢日誌來定位效能瓶頸。
2. EXPLAIN
（1） 概述
EXPLAIN可以幫助開發人員分析SQL問題，它顯示了SQL語句的執行計劃，我們可以從執行計劃中找出可以優化的地方。
（2） 使用
在SQL語句前加上EXPLAIN即可：
EXPLAIN SELECT * FROM sts
（3） 輸出結果
EXPLAIN的輸出結果由多個列組成：
id : select查詢序列號；
select_type : select語句的型別
simple: 簡單select(不使用union或子查詢)
primary: 最外面的select語句
union: union中的第二個或者後面的select語句
dependent union: union中的第二個或後面的select語句
union result: union的結果
subquery: 子查詢中的第一個select
dependent subquery: 子查詢中的第一個select，取決於外面的查詢
derived: 匯出表的select
table: 顯示從哪張表中查詢
type: 區間索引，最重要的列，顯示連線使用了何種型別
連線型別效果的排行如下所示：
system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
possible_keys: Mysql能夠使用哪個索引在該表中找到行，如果是空的，則沒有相關的索引，需要提高效能。
key: 實際使用的索引，如果為null表示沒有使用索引，如果是primary表示使用了主鍵。
key_len: 最長的索引寬度，長度越短越好
ref: 顯示使用哪個列或者常數與key一起從表中選擇行；
rows: 顯示mysql執行查詢時必須檢查的行數
Extra: 執行狀態說明，包含解決查詢的詳細資訊