mysql sql調優

個人感覺mysql的執行優化器和oracle比還是有很大的差距，oracle的很智能，好了，既然使用了mysql就不說這些的了。
要分析sql必然少不了執行計劃，只有搞清楚執行激活每個標識的意思，各個子查詢的執行順序，才能做出好的優化

一：mysql執行計劃詳解

Explain語法
EXPLAIN SELECT ……
變體：

1. EXPLAIN EXTENDED SELECT ……
   將執行計劃“反編譯”成SELECT語句，運行SHOW WARNINGS 可得到被MySQL優化器優化後的查詢語句
2. EXPLAIN PARTITIONS SELECT ……
   用於分區表的EXPLAIN
   執行計劃包含的信息
   
   id
   包含一組數字，表示查詢中執行select子句或操作表的順序
   id相同，執行順序由上至下
   如果是子查詢，id的序號會遞增，id值越大優先級越高，越先被執行
   id如果相同，可以認爲是一組，從上往下順序執行；在所有組中，id值越大，優先級越高，越先執行

select_type
表示查詢中每個select子句的類型（簡單 OR複雜）

a.SIMPLE：查詢中不包含子查詢或者UNION
b.查詢中若包含任何複雜的子部分，最外層查詢則被標記爲：PRIMARY
c.在SELECT或WHERE列表中包含了子查詢，該子查詢被標記爲：SUBQUERY
d.在FROM列表中包含的子查詢被標記爲：DERIVED（衍生）
e.若第二個SELECT出現在UNION之後，則被標記爲UNION；若UNION包含在 FROM子句的子查詢中，外層SELECT將被標記爲：DERIVED
f.從UNION表獲取結果的SELECT被標記爲：UNION RESULT

type

表示MySQL在表中找到所需行的方式，又稱“訪問類型”，常見類型如下：

由左至右，由最差到最好

a.ALL：Full Table Scan， MySQL將遍歷全表以找到匹配的行

b.index：Full Index Scan，index與ALL區別爲index類型只遍歷索引樹

c.range：索引範圍掃描，對索引的掃描開始於某一點，返回匹配值域的行，常見於between、<、>等的查詢

range訪問類型的不同形式的索引訪問性能差異

d.ref：非唯一性索引掃描，返回匹配某個單獨值的所有行。常見於使用非唯一索引即唯一索引的非唯一前綴進行的查找

e.eq_ref：唯一性索引掃描，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵或唯一索引掃描

f.const、system：當MySQL對查詢某部分進行優化，並轉換爲一個常量時，使用這些類型訪問。如將主鍵置於where列表中，MySQL就能將該查詢轉換爲一個常量

system是const類型的特例，當查詢的表只有一行的情況下， 使用system
g.NULL：MySQL在優化過程中分解語句，執行時甚至不用訪問表或索引

possible_keys

指出MySQL能使用哪個索引在表中找到行，查詢涉及到的字段上若存在索引，則該索引將被列出，但不一定被查詢使用

key
顯示MySQL在查詢中實際使用的索引，若沒有使用索引，顯示爲NULL
TIPS：查詢中若使用了覆蓋索引，則該索引僅出現在key列表中

key_len
表示索引中使用的字節數，可通過該列計算查詢中使用的索引的長度

key_len顯示的值爲索引字段的最大可能長度，並非實際使用長度，即key_len是根據表定義計算而得，不是通過表內檢索出的

ref
表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值

本例中，由key_len可知t1表的idx_col1_col2被充分使用，col1匹配t2表的col1，col2匹配了一個常量，即 ’ac’

rows
表示MySQL根據表統計信息及索引選用情況，估算的找到所需的記錄所需要讀取的行數

Extra
包含不適合在其他列中顯示但十分重要的額外信息

a.Using index

該值表示相應的select操作中使用了覆蓋索引（Covering Index）

TIPS：覆蓋索引（Covering Index）
MySQL可以利用索引返回select列表中的字段，而不必根據索引再次讀取數據文件
包含所有滿足查詢需要的數據的索引稱爲 覆蓋索引（Covering Index）

注意：
如果要使用覆蓋索引，一定要注意select列表中只取出需要的列，不可select *，因爲如果將所有字段一起做索引會導致索引文件過大，查詢性能下降

b.Using where

表示MySQL服務器在存儲引擎受到記錄後進行“後過濾”（Post-filter）,
如果查詢未能使用索引，Using where的作用只是提醒我們MySQL將用where子句來過濾結果集

c.Using temporary

表示MySQL需要使用臨時表來存儲結果集，常見於排序和分組查詢

d.Using filesort

MySQL中無法利用索引完成的排序操作稱爲“文件排序”

MySQL執行計劃的侷限

•EXPLAIN不會告訴你關於觸發器、存儲過程的信息或用戶自定義函數對查詢的影響情況
•EXPLAIN不考慮各種Cache
•EXPLAIN不能顯示MySQL在執行查詢時所作的優化工作
•部分統計信息是估算的，並非精確值
•EXPALIN只能解釋SELECT操作，其他操作要重寫爲SELECT後查看執行計劃

二：mysql中常見的hint

如果可以通過改寫sql來實現，則優先改寫sql，不要隨意使用hint，一定要嚴格測試，使用hint後不一定比之前快，不要想當然
有時寫的sql,通過查看執行計劃，發現沒有按照最優的路線走，並且執行緩慢，則可以通過hint提示來調優
對於經常使用oracle的朋友可能知道，oracle的hint功能種類很多，對於優化sql語句提供了很多方法。同樣，在mysql裏，也有類似的hint功能。下面介紹一些常用的。
強制索引 FORCE INDEX
SELECT * FROM TABLE1 FORCE INDEX (INDEX2) …
以上的SQL語句只使用INDEX2索引。
忽略索引 IGNORE INDEX
SELECT * FROM TABLE1 IGNORE INDEX (FIELD1, FIELD2) …
在上面的SQL語句中，TABLE1表中FIELD1和FIELD2上的索引不被使用。
關閉查詢緩衝 SQL_NO_CACHE
SELECT SQL_NO_CACHE field1, field2 FROM TABLE1;
有一些SQL語句需要實時地查詢數據，或者並不經常使用（可能一天就執行一兩次）,這樣就需要把緩衝關了,不管這條SQL語句是否被執行過，服務器都不會在緩衝區中查找，每次都會執行它。
強制查詢緩衝 SQL_CACHE
SELECT SQL_CALHE * FROM TABLE1;
如果在my.ini中的query_cache_type設成2，這樣只有在使用了SQL_CACHE後，才使用查詢緩衝。

優先操作 HIGH_PRIORITY
HIGH_PRIORITY可以使用在select和insert操作中，讓MYSQL知道，這個操作優先進行。
SELECT HIGH_PRIORITY * FROM TABLE1;
滯後操作 LOW_PRIORITY
LOW_PRIORITY可以使用在insert和update操作中，讓mysql知道，這個操作滯後。
update LOW_PRIORITY table1 set field1= where field1= …
延時插入 INSERT DELAYED
INSERT DELAYED INTO table1 set field1= …
INSERT DELAYED INTO，是客戶端提交數據給MySQL，MySQL返回OK狀態給客戶端。而這時並不是已經將數據插入表，而是存儲在內存裏面等待排隊。當mysql有空餘時，再插入。另一個重要的好處是，來自許多客戶端的插入被集中在一起，並被編寫入一個塊。這比執行許多獨立的插入要快很多。壞處是，不能返回自動遞增的ID，以及系統崩潰時，MySQL還沒有來得及插入數據的話，這些數據將會丟失。

強制連接順序 STRAIGHT_JOIN
SELECT TABLE1.FIELD1, TABLE2.FIELD2 FROM TABLE1 STRAIGHT_JOIN TABLE2 WHERE …
由上面的SQL語句可知，通過STRAIGHT_JOIN強迫MySQL按TABLE1、TABLE2的順序連接表。如果你認爲按自己的順序比MySQL推薦的順序進行連接的效率高的話，就可以通過STRAIGHT_JOIN來確定連接順序。
STRAIGHT_JOIN只適用於inner join，並不適用於left join，right join，因爲left join，right join已經代表指定了表的執行順序

強制使用臨時表 SQL_BUFFER_RESULT
SELECT SQL_BUFFER_RESULT * FROM TABLE1 WHERE …
當我們查詢的結果集中的數據比較多時，可以通過SQL_BUFFER_RESULT.選項強制將結果集放到臨時表中，這樣就可以很快地釋放MySQL的表鎖（這樣其它的SQL語句就可以對這些記錄進行查詢了），並且可以長時間地爲客戶端提供大記錄集。
分組使用臨時表 SQL_BIG_RESULT和SQL_SMALL_RESULT
SELECT SQL_BUFFER_RESULT FIELD1, COUNT(*) FROM TABLE1 GROUP BY FIELD1;
一般用於分組或DISTINCT關鍵字，這個選項通知MySQL，如果有必要，就將查詢結果放到臨時表中，甚至在臨時表中進行排序。SQL_SMALL_RESULT比起SQL_BIG_RESULT差不多，很少使用。

三：優化例子

1.連接順序調整，及強制使用索引

1）如下，tb1,大表，不應該被作爲開始表，tb4分頁子查詢，最多隻有15條數據，應該被作爲開始表，優化前執行時間0.341秒

2）使用STRAIGHT_JOIN做如下優化，優化後執行時間0.224秒，感覺優化力度不大，有可能是tb1的數據量還不夠大

3）第二步優化後發現連接tb1的時候還是走的全表掃描，沒有使用上主鍵索引，這裏強制使用主鍵索引FORCE INDEX (primary) ，優化後執行時間0.024

參考文檔
https://www.cnblogs.com/ggjucheng/archive/2012/11/11/2765237.html
https://www.cnblogs.com/jpfss/p/11490765.html