SQL優化指南

慢查詢日誌 開啓撒網模式

    開啓了MySQL慢查詢日誌以後，MySQL會自動將執行時間超過指定秒數的SQL通通記錄下來，這對於蒐羅線上慢SQL有很大的幫助。

SHOW VARIABLES LIKE 'slow%'

以我剛安裝的mysql5.7爲例 查詢結果是這樣子的：

　　slow_launch_time：表示若是創建線程花費了比這個值更長的時間,slow_launch_threads 計數器將增長
　　slow_query_log：是否開啓慢查詢日誌 ON開啓，OFF關閉 默認沒有開啓
　　slow_query_log_file：日誌保存路徑

SHOW VARIABLES LIKE 'long%'

　　long_query_time：達到多少秒的sql就記錄日誌

客戶端能夠用set設置變量的方式讓慢查詢開啓，可是我的不推薦，由於真實操做起來會有一些問題，好比說，重啓MySQL後就失效了，或者是開啓了慢查詢，我又去改變量值，它就不生效了。

編輯MySQL的配置文件：

vim /etc/my.cnf

加入以下三行：

　　slow_query_log=ON
　　slow_query_log_file=/var/lib/mysql/localhost-centos-slow.log
　　long_query_time=3

我這裏設置的是3秒

 重啓MySQL

systemctl restart mysqld;

服務器開一個監控：

tail -f /var/lib/mysql/localhost-centos-slow.log

客戶端走一條SQL：

SELECT SLEEP(3)

此時發現sql已經被記錄到日誌裏了。（有時候不必定，我看到不少博客講的是超過指定秒數，但我實驗得出的結果是達到指定秒數）

EXPLAIN 點對點分析你

　　explain是一個神奇的命令，能夠查看sql的具體的執行計劃。

以一條聯查sql爲例：

SELECT a.id,a.cn_name,a.role_id,r.name
FROM tb_usr_admins a
INNER JOIN tb_base_roles r ON r.id=a.role_id
WHERE a.cn_name="接單人員"

 

查詢結果是：

加上explain命令來執行：

EXPLAIN
SELECT a.id,a.cn_name,a.role_id,r.name
FROM tb_usr_admins a
INNER JOIN tb_base_roles r ON r.id=a.role_id
WHERE a.cn_name="接單人員"

查詢結果是：

這就是這條SQL的執行計劃，下面來講明一下這個執行計劃怎麼看

　　id：表明優先級  id值越大，越先執行，id值相同，從上往下執行。（好比示例的這條sql的執行計劃，就是先執行第一行，再執行第二行）

　　select_type：表示select類型 取值以下

　　　　simple 簡單表 即不使用錶鏈接或者子查詢
　　　　primary 包含union或者子查詢的主查詢 即外層的查詢
　　　　union UNION中的第二個或者後面的查詢語句
　　　　subquery 通常子查詢中的子查詢被標記爲subquery，也就是位於select列表中的查詢
　　　　derived 派生表 該臨時表是從子查詢派生出來的
　　　　等等

　　type：表示MySQL在表中查找數據的方式，或者叫訪問類型，如下對於type取值的說明 從上往下性能由最差到最好

　　　　all:全表掃描，MySQL遍歷全表來找到匹配的行
　　　　index：索引全掃描，MySQL遍歷掙個索引來查詢匹配的行
　　　　range：索引範圍掃描，常見於<、<=、>、>=、between等操做符
　　　　ref：使用非惟一索引或惟一索引的前綴掃描，返回匹配的單行數據
　　　　eq_ref：相似ref，區別就在於使用的索引是惟一索引，簡單來講，就是多表鏈接中使用primary key或者unique index做爲關聯條件。
　　　　const/system：單表中最多有一個匹配行，查詢起來很是迅速，常見於根據primary key或者惟一索引unique index進行的單表查詢
　　　　null：mysql不用訪問表或者索引，直接就可以獲得查詢的結果，例如select 1+2 as result。

　　possible_keys：表示查詢時可能使用的索引

　　key：表示實際使用的索引

　　key_len：使用到索引字段的長度

　　rows：掃描數量

　　Extra：執行狀況的說明和描述，包含不適合在其餘列中顯示可是對執行計劃很是重要的額外信息，經常使用取值以下：

　　　　Using index：直接訪問索引就取到了數據，高性能的表現。
　　　　Using where：直接在主鍵索引上過濾數據，必帶where子句，並且用不上索引
　　　　Using index condition：先條件過濾索引，再查數據，
　　　　Using filesort：使用了外部文件排序 只要見到這個 就要優化掉
　　　　Using temporary：建立了臨時表來處理查詢 只要見到這個 也要儘可能優化掉

優化爭議無數的count()

統計列與統計行？

　　COUNT()是一個特殊的函數，有兩種不一樣的做用，它能夠統計某個列值的數量，也能夠統計行數。

　　在統計列值的時候要求列值是非空的，也就是不統計null。

　　當咱們統計行的時候，常見的是COUNT(*)，這種狀況下，通配符*並不會像咱們猜測的那樣擴展成全部的列，實際上，它會忽略全部的列而直接統計全部的行數

解密MyiSAM的‘快’

　　這是一個容易產生誤解的事情：MyiSAM的count()函數老是很是快。

　　不過它是有前提條件的，條件是沒有任何where條件的count(*)才很是快，由於此時無須實際的去計算表的行數，mysql能夠利用存儲引擎的特性直接得到這個值，若是mysql知道某列不可能有null值，那麼mysql內部會將count(列)表達式優化爲count(*)。

　　當統計帶有where條件的查詢，那麼mysql的count()和其餘存儲引擎就沒有什麼不一樣了。

COUNT(1)、COUNT(*)、COUNT(列)

　　（先提早申明，本人是在innodb庫裏作的實驗。）

　　1.count(1)和count(*)直接就是統計主鍵，他們兩個的效率是同樣的。若是刪除主鍵，他們都走全表掃描。

　　2.若是count(列)中的字段是索引的話，count(列)和count(*)同樣快，不然count(列)走全表掃描。

優化order by 語句

MySQL的排序方式

　　優化order by語句就不得不瞭解mysql的排序方式。

　　1.第一種經過有序索引返回數據，這種方式的extra顯示爲Using Index,不須要額外的排序，操做效率較高。

　　2.第二種是對返回的數據進行排序，也就是一般看到的Using filesort，filesort是經過相應的排序算法，將數據放在sort_buffer_size系統變量設置的內存排序區中進行排序，若是內存裝載不下，它就會將磁盤上的數據進行分塊，再對各個數據塊進行排序，而後將各個塊合併成有序的結果集。

filesort的優化

　　瞭解了MySQL排序的方式，優化目標就清晰了：儘可能減小額外的排序，經過索引直接返回有序數據。where條件和order by使用相同的索引。

　　1.建立合適的索引減小filesort的出現。

　　2.查詢時儘可能只使用必要的字段，select 具體字段的名稱，而不是select * 選擇全部字段，這樣能夠減小排序區的使用，提升SQL性能。

優化group by 語句

爲何order by後面不能跟group by ?

　　事實上，MySQL在全部的group by 後面隱式的加了order by ，也就是說group by語句的結果會默認進行排序。

　　若是你要在order by後面加group by ，那結果執行的SQL是否是這樣：select * from tb order by ... group by ... order by ... ？ 這不是搞笑嗎？

禁止排序

　　既然知道問題了，那麼就容易優化了，若是查詢包括group by但又不關心結果集的順序，而這種默認排序又致使了須要文件排序，則能夠指定order by null 禁止排序。

例如：

select * from tb group by name order by null;

優化limit 分頁

　　一個很是常見又很是頭痛的場景：‘limit 1000,20’。

　　這時MySQL須要查詢1020條記錄而後只返回最後20條，前面的1000條都將被拋棄，這樣的代價很是高。若是全部頁面的訪問頻率都相同，那麼這樣的查詢平均須要訪問半個表的數據。

第一種思路 在索引上分頁

　　在索引上完成分頁操做，最後根據主鍵關聯回原表查詢所須要的其餘列的內容。

例如：

SELECT * FROM tb_user LIMIT 1000,10

能夠優化成這樣：

SELECT * FROM tb_user u 
INNER JOIN (SELECT id FROM tb_user LIMIT 1000,10) AS b ON b.id=u.id

第二種思路 將limit轉換成位置查詢

這種思路須要加一個參數來輔助，標記分頁的開始位置：

SELECT * FROM tb_user WHERE id > 1000 LIMIT 10

優化子查詢

　　子查詢，也就是查詢中有查詢，常見的是where後面跟一個括號裏面又是一條查詢sql

　　儘量的使用join關聯查詢來代替子查詢。

　　固然 這不是絕對的，好比某些很是簡單的子查詢就比關聯查詢效率高，事實效果如何還要看執行計劃。

　　只能說大部分的子查詢均可以優化成Join關聯查詢。

改變執行計劃

提升索引優先級

　　use index 可讓MySQL去參考指定的索引，可是沒法強制MySQL去使用這個索引，當MySQL以爲這個索引效率太差，它寧願去走全表掃描。。。

SELECT * FROM tb_user USE INDEX (user_name)

　　注意：必須是索引，不能是普通字段，（親測主鍵也不行）。

忽略索引

　　ignore index 可讓MySQL忽略一個索引

SELECT * FROM tb_user IGNORE INDEX (user_name) WHERE user_name="張學友" 

強制使用索引

　　force index 使用了force index 以後 儘管效率很是低，MySQL也會照你的話去執行

SELECT * FROM tb_user FORCE INDEX (user_name) WHERE user_name="張學友" 

我的分享

查看執行計劃時建議依次觀察如下幾個要點：

　　1.SQL內部的執行順序。
　　2.查看select的查詢類型。
　　3.實際有沒有使用索引。
　　4.Extra描述信息

PS:必定要養成查看執行計劃的習慣，這個習慣很是重要。