目錄
查詢執行流程圖
客戶端/服務端通訊
通訊狀態查詢
查詢快取
為什麼mysql 8.0預設關閉了快取開啟？
查詢優化處理
explain
查詢執行引擎
返回客戶端
注：mysql8.0已取消查詢快取
mysql客戶端與服務端的通訊方式是「半雙工」。
全雙工：雙向通訊，傳送同時也可以接收；
半雙工：雙向通訊，同一時間只能接收或者是傳送，無法同時做操作；
單工：只能單一方向傳送。
對於乙個mysql連線，或者說乙個執行緒，時刻都有乙個狀態來標識這個連線正在做什麼。
檢視命令： show full processlist / show processlist
sleep：執行緒正在等待客戶端傳送資料；
query：連線線程正在執行查詢；
locked：執行緒正在等待表鎖的釋放；
sorting result：執行緒正在對結果進行排序；
sending data：向請求端返回資料。
可通過kill 的方式將連線的殺掉。
以key-value形式快取查詢的結果集，key為sql，value為sql的查詢結果集。新的查詢到來時會將sql與快取的key進行匹配。
通過引數query_cache_type可以控制快取的使用。
0 ： 不啟用查詢快取，預設值；
1 ： 啟用查詢快取，只要符合查詢快取的要求，客戶端的查詢語句和記錄集都可以快取起來，供其他客戶端使用，加上 sql_no_cache將取消快取。
2 ： 啟用查詢快取，只要查詢語句中新增了引數：sql_cache，且符合查詢快取的要求，客戶端的查詢語句和記錄集，則可以快取起來，供其他客戶端使用。
1. 在查詢之前必須先檢查是否命中快取，浪費計算資源；
2. 如果這個查詢可以被快取，那麼執行完成後，mysql發現查詢快取中沒有這個查詢，則會將結果存入查詢快取，這會帶來額外的系統消耗；
3. 針對表進行寫入或更新資料時，將對應表的所有快取都設定失效；
4. 如果查詢快取很大或者碎片很多時，這個操作可能帶來很大的系統消耗。
查詢優化處理的三個階段：
1. 解析sql：通過lex詞法分析，yacc語法分析將sql語句解析成解析樹;
2. 預處理階段：根據mysql的語法的規則進一步檢查解析樹的合法性，如檢查資料的表和列是否存在，解析名字和別名的設定，還會進行許可權的驗證；
3. 查詢優化器：
使用等價變化規則：5 = 5 and a > 5 優化為 a > 5；a < b and a = 5 優化為 b > 5 and a = 5；基於聯合索引，調整條件位置等。
優化count 、min、max等函式：min函式只需找索引最左邊；max函式只需找索引最右邊。
覆蓋索引掃瞄：避免二次查詢。
提前終止查詢：用了limit關鍵字或者使用不存在的條件。
in的優化：先進行排序，再採用二分查詢。
id：select查詢的序列號，標識執行的順序。
1. id相同，執行順序由上至下；
2. id不同，如果是子查詢，id的序號會遞增，id值越大優先順序越高，越先被執行；
3. id相同又不同即兩種情況同時存在，id如果相同，可以認為是一組，從上往下順序執行；在所有組中，id值越大，優先順序越高，越先執行。
select_type：查詢的型別，主要是用於區分普通查詢、聯合查詢、子查詢等。
1. ******：簡單的select查詢，查詢中不包含子查詢或者union；
2. primary：查詢中包含子部分，最外層查詢則被標記為primary；
3. subquery/materialized：subquery表示在select 或 where列表中包含了子查詢，materialized表示where 後面in條件的子查詢。
4. union：若第二個select出現在union之後，則被標記為union；
5. union result：從union表獲取結果的select。
table：查詢設計的表。
type：訪問型別。
sql查詢優化中乙個很重要的指標，結果值從好到壞依次是：system > const > eq_ref > ref > range > index > all
1. system：表只有一行記錄（等於系統表），const型別的特例，基本不會出現，可以忽略不計；
2. const：表示通過索引一次就找到了，const用於比較primary key 或者 unique索引；
3. eq_ref：唯一索引掃瞄，對於每個索引鍵，表中只有一條記錄與之匹配。常見於主鍵 或 唯一索引掃瞄；
4. ref：非唯一性索引掃瞄，返回匹配某個單獨值的所有行，本質是也是一種索引訪問；
5. range：只檢索給定範圍的行，使用乙個索引來選擇行；
6. index：full index scan，索引全掃瞄，把索引從頭到尾掃一遍；
7. all：full table scan，遍歷全表以找到匹配的行。
possible_keys：查詢過程中有可能用到的索引。
key：實際使用的索引，如果為null，則沒有使用索引。
rows：根據表統計資訊或者索引選用情況，大致估算出找到所需的記錄所需要讀取的行數。
filtered：它指返回結果的行佔需要讀到的行(rows列的值)的百分比，filtered的值越大越好。
extera：十分重要的額外資訊。
1. using filesort ：mysql對資料使用乙個外部的檔案內容進行了排序，而不是按照表內的索引進行排序讀取；
2. using temporary：使用臨時表儲存中間結果，也就是說mysql在對查詢結果排序時使用了臨時表，常見於order by 或 group by；
3. using index：表示相應的select操作中使用了覆蓋索引（covering index），避免了訪問表的資料行，效率較高；
4. using where ：使用了where過濾條件；
5. select tables optimized away：基於索引優化min/max操作或者myisam儲存引擎優化count(*)操作，不必等到執行階段在進行計算，查詢執行計畫生成的階段即可完成優化。
呼叫外掛程式式的儲存引擎的原子api的功能進行執行計畫的執行。
1. 有需要做快取的，執行快取操作；
2. 增量的返回結果。開始生成第一條結果時，mysql就開始往請求方逐步返回資料，這樣一來，mysql伺服器無須儲存過多的資料，避免記憶體浪費，還可以提公升使用者體驗，馬上拿到資料。
查詢優化（MySQL優化查詢）
關聯查詢太多join 設計缺陷或不得已的需求 資料庫伺服器調優及各個引數設定不適當 緩衝 執行緒數等 慢查詢日誌 找出執行速度慢的sql語句 慢查詢的開啟並捕獲 explain 慢sql分析 show profile查詢sql在mysql伺服器裡面的執行細節和生命週期情況 sql資料庫伺服器的引數調...
mysql統計查詢優化 Mysql查詢優化
效能涉及的層面很多，但是在操作層面，主要有表結構設計優化 索引優化和查詢優化 查詢的生命週期大致可以分為，從客戶端 到服務端 在伺服器上解析 生成執行計畫 執行 返回結果給客戶端 sql執行流程 具體優化技巧 1.消除外連線 2.消除子查詢 盡量用join代替子查詢，雖說mysql查詢優化器會進行優...
MySQL優化 查詢優化
在每乙個消耗大量時間的查詢中，都能看到一些不必要的額外操作 某些操作被額外地重複了很多次 某些操作執行得太慢等。優化查詢的目的就是減少和消除這些操作所花費的時間。查詢效能低下最基本的原因是訪問的資料太多。所以需要考慮是否向資料庫請求了不需要的資料 1 多表關聯時，或獲取單錶資料時，盡量避免不加思考地...