文章目錄
背景
在應用的的開發過程中，由於初期數據量小，開發人員寫 SQL 語句時更重視功能上的實現，但是當應用系統正式上線後，隨着生產數據量的急劇增長，很多 SQL 語句開始逐漸顯露出性能問題，對生產的影響也越來越大，此時這些有問題的 SQL 語句就成爲整個系統性能的瓶頸，因此我們必須要對它們進行優化，本章將詳細介紹在 MySQL 中優化 SQL 語句的方法。
當面對一個有 SQL 性能問題的數據庫時，我們應該從何處入手來進行系統的分析，使得能夠儘快定位問題 SQL 並儘快解決問題。
查看sql執行效率
MySQL 客戶端連接成功後，通過 show [session|global] status 命令可以提供服務器狀態信息。show [session|global] status 可以根據需要加上參數“session”或者“global”來顯示 session 級（當前連接）的計結果和 global 級（自數據庫上次啓動至今）的統計結果。如果不寫，默認使用參數是“session”。
下面的命令顯示了當前 session 中所有統計參數的值：
show status like ‘Com_______’;
show status like ‘Innodb_rows_%’;
Com_xxx 表示每個 xxx 語句執行的次數，我們通常比較關心的是以下幾個統計參數。
| 參數 | 含義 |
|---|---|
| Com_select | 執行 select 操作的次數，一次查詢只累加 1。 |
| Com_insert | 執行 INSERT 操作的次數，對於批量插入的 INSERT 操作，只累加一次。 |
| Com_update | 執行 UPDATE 操作的次數。 |
| Com_delete | 執行 DELETE 操作的次數。 |
| Innodb_rows_read | select 查詢返回的行數。 |
| Innodb_rows_inserted | 執行 INSERT 操作插入的行數。 |
| Innodb_rows_updated | 執行 UPDATE 操作更新的行數。 |
| Innodb_rows_deleted | 執行 DELETE 操作刪除的行數。 |
| Connections | 試圖連接 MySQL 服務器的次數。 |
| Uptime | 服務器工作時間。 |
| Slow_queries | 慢查詢的次數。 |
Com_*** : 這些參數對於所有存儲引擎的表操作都會進行累計。
Innodb_*** : 這幾個參數只是針對InnoDB 存儲引擎的，累加的算法也略有不同。
定位低效率執行SQL
可以通過以下兩種方式定位執行效率較低的 SQL 語句。
- 慢查詢日誌 : 通過慢查詢日誌定位那些執行效率較低的 SQL 語句，用–log-slow-queries[=file_name]選項啓動時，mysqld 寫一個包含所有執行時間超過 long_query_time 秒的 SQL 語句的日誌文件。具體可以查看本書第 26 章中日誌管理的相關部分。
- show processlist : 慢查詢日誌在查詢結束以後才紀錄，所以在應用反映執行效率出現問題的時候查詢慢查詢日誌並不能定位問題，可以使用show processlist命令查看當前MySQL在進行的線程，包括線程的狀態、是否鎖表等，可以實時地查看 SQL 的執行情況，同時對一些鎖表操作進行優化。
![在這裏插入圖片描述]()
1） id列，用戶登錄mysql時，系統分配的"connection_id"，可以使用函數connection_id()查看
2） user列，顯示當前用戶。如果不是root，這個命令就只顯示用戶權限範圍的sql語句
3） host列，顯示這個語句是從哪個ip的哪個端口上發的，可以用來跟蹤出現問題語句的用戶
4） db列，顯示這個進程目前連接的是哪個數據庫
5） command列，顯示當前連接的執行的命令，一般取值爲休眠（sleep），查詢（query），連接（connect）等
6） time列，顯示這個狀態持續的時間，單位是秒
7） state列，顯示使用當前連接的sql語句的狀態，很重要的列。state描述的是語句執行中的某一個狀態。一個sql語句，以查詢爲例，可能需要經過copying to tmp table、sorting result、sending data等狀態纔可以完成
8） info列，顯示這個sql語句，是判斷問題語句的一個重要依據
explain分析執行計劃
通過以上步驟查詢到效率低的 SQL 語句後，可以通過 EXPLAIN或者 DESC命令獲取 MySQL如何執行 SELECT 語句的信息，包括在 SELECT 語句執行過程中表如何連接和連接的順序。
查詢SQL語句的執行計劃 ：
explain select * from tb_item where id = 1;
| 字段 | 含義 |
|---|---|
| id | select查詢的序列號，是一組數字，表示的是查詢中執行select子句或者是操作表的順序。 |
| select_type | 表示 SELECT 的類型，常見的取值有 SIMPLE（簡單表，即不使用表連接或者子查詢）、PRIMARY（主查詢，即外層的查詢）、UNION（UNION 中的第二個或者後面的查詢語句）、SUBQUERY（子查詢中的第一個 SELECT）等 |
| table | 輸出結果集的表 |
| type | 表示表的連接類型，性能由好到差的連接類型爲( system —> const -----> eq_ref ------> ref -------> ref_or_null----> index_merge —> index_subquery -----> range -----> index ------> all ) |
| possible_keys | 表示查詢時，可能使用的索引 |
| key | 表示實際使用的索引 |
| key_len | 索引字段的長度 |
| rows | 掃描行的數量 |
| extra | 執行情況的說明和描述 |
explain 之 id
id 字段是 select查詢的序列號，是一組數字，表示的是查詢中執行select子句或者是操作表的順序。id 情況有三種 ：
1） id 相同表示加載表的順序是從上到下。
2） id 不同id值越大，優先級越高，越先被執行。
3） id 有相同，也有不同，同時存在。id相同的可以認爲是一組，從上往下順序執行；在所有的組中，id的值越大，優先級越高，越先執行。
explain 之 select_type
表示 SELECT 的類型，常見的取值，如下表所示：
| select_type | 含義 |
|---|---|
| SIMPLE | 簡單的select查詢，查詢中不包含子查詢或者UNION |
| PRIMARY | 查詢中若包含任何複雜的子查詢，最外層查詢標記爲該標識 |
| SUBQUERY | 在SELECT 或 WHERE 列表中包含了子查詢 |
| DERIVED | 在FROM 列表中包含的子查詢，被標記爲 DERIVED（衍生） MYSQL會遞歸執行這些子查詢，把結果放在臨時表中 |
| UNION | 若第二個SELECT出現在UNION之後，則標記爲UNION ； 若UNION包含在FROM子句的子查詢中，外層SELECT將被標記爲 ： DERIVED |
| UNION RESULT | 從UNION表獲取結果的SELECT |
explain 之 table
展示這一行的數據是關於哪一張表的
explain 之 type
type 顯示的是訪問類型，是較爲重要的一個指標，可取值爲：
| type | 含義 |
|---|---|
| NULL | MySQL不訪問任何表，索引，直接返回結果 |
| system | 表只有一行記錄(等於系統表)，這是const類型的特例，一般不會出現 |
| const | 表示通過索引一次就找到了，const 用於比較primary key 或者 unique 索引。因爲只匹配一行數據，所以很快。如將主鍵置於where列表中，MySQL 就能將該查詢轉換爲一個常亮。const於將 “主鍵” 或 “唯一” 索引的所有部分與常量值進行比較 |
| eq_ref | 類似ref，區別在於使用的是唯一索引，使用主鍵的關聯查詢，關聯查詢出的記錄只有一條。常見於主鍵或唯一索引掃描 |
| ref | 非唯一性索引掃描，返回匹配某個單獨值的所有行。本質上也是一種索引訪問，返回所有匹配某個單獨值的所有行（多個） |
| range | 只檢索給定返回的行，使用一個索引來選擇行。 where 之後出現 between ， < , > , in 等操作。 |
| index | index 與 ALL的區別爲 index 類型只是遍歷了索引樹， 通常比ALL 快， ALL 是遍歷數據文件。 |
| all | 將遍歷全表以找到匹配的行 |
結果值從最好到最壞以此是：
NULL > system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
system > const > eq_ref > ref > range > index > ALL
一般來說， 我們需要保證查詢至少達到 range 級別， 最好達到ref 。
explain 之 key
possible_keys : 顯示可能應用在這張表的索引， 一個或多個。
key ： 實際使用的索引， 如果爲NULL， 則沒有使用索引。
key_len : 表示索引中使用的字節數， 該值爲索引字段最大可能長度，並非實際使用長度，在不損失精確性的前提下， 長度越短越好 。
explain 之 rows
掃描行的數量。
explain 之 extra
其他的額外的執行計劃信息，在該列展示 。
| extra | 含義 |
|---|---|
| using filesort | 說明mysql會對數據使用一個外部的索引排序，而不是按照表內的索引順序進行讀取， 稱爲 “文件排序”, 效率低。 |
| using temporary | 使用了臨時表保存中間結果，MySQL在對查詢結果排序時使用臨時表。常見於 order by 和 group by； 效率低 |
| using index | 表示相應的select操作使用了覆蓋索引， 避免訪問表的數據行， 效率不錯。 |
show profile分析SQL
Mysql從5.0.37版本開始增加了對 show profiles 和 show profile 語句的支持。show profiles 能夠在做SQL優化時幫助我們瞭解時間都耗費到哪裏去了。
通過 have_profiling 參數，能夠看到當前MySQL是否支持profile：
默認profiling是關閉的，可以通過set語句在Session級別開啓profiling：
set profiling=1; //開啓profiling 開關；
通過profile，我們能夠更清楚地瞭解SQL執行的過程。
首先，我們可以執行一系列的操作，如下圖所示：
show databases;
use db01;
show tables;
select * from tb_item where id < 5;
select count(*) from tb_item;
執行完上述命令之後，再執行show profiles 指令， 來查看SQL語句執行的耗時，再獲取到最消耗時間的線程狀態後，MySQL支持進一步選擇all、cpu、block io 、context switch、page faults等明細類型類查看MySQL在使用什麼資源上耗費了過高的時間。例如，選擇查看CPU的耗費時間 。
| 字段 | 含義 |
|---|---|
| Status | sql 語句執行的狀態 |
| Duration | sql 執行過程中每一個步驟的耗時 |
| CPU_user | 當前用戶佔有的cpu |
| CPU_system | 系統佔有的cpu |
本文參考www.itheima.com學習資料，只用於本人學習筆記總結，不可轉載，如有侵權請諒解。