MySQL執行計劃複習

MySQL執行計劃分析

Ⅰ、認識執行計劃的每一個字段

(root@localhost) [(none)]> desc select 1;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra          |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
|  1 | SIMPLE      | NULL  | NULL       | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | No tables used |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+----------------+
1 row in set, 1 warning (0.00 sec)

1.1 id

• 單純的join，id都是1，且從上到下
• subquery、scala subquery都會使id遞增

1.2 select type

• simple
  • 不使用union或者subquery的簡單query
  • 子查詢被優化器打開，失效了
• primary
  • 使用union結合select時，第一個select type
  • subquery的query
• union
  • 使用union結合select除了第一個select type爲primary，其他爲union(extra中union result是union去掉重複值的臨時表)
  • 5.7開始union all不會出現union result，由於不去重
• subquery
  • 不是用在from後面的subquery
  • 和外部表無關聯
  • subquery(標量子查詢)執行計劃沒錯誤，不表明sql執行沒錯(不能超過1行數據，subquery return more than 1 row)
• dependent subquery
  • 必須依附於外面的值
  • scala subquery(和外部有關係的標量子查詢)
  • exists
• derived
  • from位置以後的subquery
  • derived是生成在內存或者臨時表空間中
  • 若是derived做驅動表時，要點是減小數據量
  • 看成被驅動表時產生auto_key索引，也是以減小數據量爲目
  • 5.7中optimizer_switch='derived_merge=on'能夠把簡單subquery打開成join
  • derived_merge爲on時被驅動表的鏈接條件要有索引，爲off時被驅動表結果集要小
  • 5.7的derived_merge可能致使子查詢中order by失效
  • 5.7如下操做能夠防止derived_merge
    • unin/union all
    • group by
    • distinct
    • 聚合函數
    • limit
    • @
• materialized
  • 物化，5.7開始in會產生，也會生成auto_key索引
  • in中使用hint QB_NAME，外層使用這個hint
    • select /+ semijoin(@sub MATERIALIZATION) / * from t_order t2 where t2.emp_no in (select /+ QB_NAME(sub) / t1.emp_no from dept_emp t1);

1.3 table

• NULL
  • 表示不使用任何表
  • 使用dual
  • extra中出現select tables optimized away,多見於count操做
• 表名或者表的別名
• <derived+ id><union + id>
  • 臨時表<>裏的數字是id列
  • tmp_table_size = max_heap_table_size適當調大

1.4 type

• const
  • 使用primary key或者unique key取得一條數據
• eq_ref
  • join，且知足被驅動表的鏈接條件unique key或者primary key
• ref
  • 對索引列作等號判斷
• range
  • between in like > <
  • 和const的區別在於索引掃描範圍不同
• index
  • 索引全掃描，比掃全表且order by的狀況快，可是絕大部分狀況下也是優化對象
  • 不能使用range，const，ref的狀況下，且只查詢索引列，即不回表，使用索引進行排序或者聚合即省略排序
  • 索引(a,b),select a from xxx where b = ''; 即聯合索引中前導列不在where條件中，且查詢列在索引中
  • 在聚合運算中group by後面的列在索引或者primary key中，且查詢列也在索引中
• all
  • 全表掃描
  • 大表中查詢超過一半以上的值，效果更好
  • 索引失效
    • 無索引
    • 對索引列加工
    • 索引列隱式類型轉換
    • 對日期類型進行like '20xxx'
    • 單列索引，對數字列進行like '30%'

1.5 possible_keys

• 列出可能用到的索引，對優化沒什麼幫助
• 5.6以後開始支持auto_key
• auto_key就是臨時建立索引，須要消耗一些內存和cpu，對tmp_table_size，max_heap_table_size依賴較大
• mysql列大小超過767個字節，沒法生成auto_key
• convert(xxx,數據類型,字符集)

1.6 key

• sql用到的索引

1.7 key_len

• 顯示sql到底使用了多少索引

1.8 ref

• 只有type是ref或者const纔會出現內容，沒啥用，不用管

1.9 rows

• MySQL優化器根據統計信息預估出來的值，不許

1.10 filter

• 和rows同樣是預估值，非100的狀況是extra有using where關鍵字，表示從存儲引擎中拿到數據後再加工的比例
• 5.7開始該值比較準確

1.11 Extra

• Distinct
  • MySQL在join過程當中取出一行以後查詢另外一個表時，碰到一行就中止，有點像exsits
  • 必須是join
  • distinct關鍵字
  • select列上只能含有驅動表的字段
  • 使用straight_join hint能夠強制改變驅動表
• select tables optimized away
  • 查詢中只有min、max的時候出現，有時候count貌似也會出現
  • 聯合主鍵，其中任一一個字段用等值查詢，查出另外一個字段的min或max，且不能包含group by
• Using filesort
  • order by, group by且沒使用索引
  • 8.0 group by不會出現
• Using index
  • 只使用索引不回表就能夠查到
  • 若是表對應的where條件選擇率不是很好，且一行長度很長，此時課考慮建立包含對應列的索引達到減小物理io的目的
  • 延遲join必須使用using index，不然無效
• Using temporary
  • sql執行過程當中存儲中間結果會使用tempoary table，但沒法判斷在內存仍是disk
  • order by,group by未使用索引
  • 執行計劃中的select type爲derived
  • show swssion status like '%tmp%'
  • max_heap_table_size和tmp_table_size(不一致時以小的爲準)
• Using where
  • 通常和filtered，rows一塊兒看
  • 表示從存儲引擎中拿到數據再過濾
  • rows是存儲引擎中拿數據的預估值，filtered是再過濾的百分比
• Using index condition
  • 必須是二級索引纔有,且有索引後面部分沒法使用時，回表次數很大，效果更好
  • optimizer_switch='index_condition_pushdown=on'
• Using MRR
  • optimizer_switdch='mrr_cost_based=0ff'
  • 回表以前先排序，下降隨機io
• Range checked for each record
  • type爲all
  • 這是優化對象，緊接着用show warnings來定位問題
• Using join buffer(Block Nested Loop)
  • optimizer_switch='block_nested_loop=on,batched_key_access=on'
  • 被驅動表沒有索引且數據量較少的時候，通常這種狀況也是優化對象

Ⅱ、獲取運行中SQL的執行計劃

desc for connection connection_id;