explain顯示了mysql如何使用索引來處理select語句以及連線表。可以幫助選擇更好的索引和寫出更優化的查詢語句。簡單講，它的作用就是分析查詢效能。
explain關鍵字的使用方法很簡單，就是把它放在select查詢語句的前面。
mysql檢視是否使用索引，簡單的看type型別就可以。如果它是all，那說明這條查詢語句遍歷了所有的行，並沒有使用到索引。
比如：explain select * from company_info where cname like '%小%'
explain select * from company_info where cname like '小%'
以下1）、id列數字越大越先執行，如果說數字一樣大，那麼就從上往下依次執行，id列為null的就表是這是乙個結果集，不需要使用它來進行查詢。
2）、select_type列常見的有：
3）、table
顯示的查詢表名，如果查詢使用了別名，那麼這裡顯示的是別名，如果不涉及對資料表的操作，那麼這顯示為null，如果顯示為尖括號括起來的就表示這個是臨時表，後邊的n就是執行計畫中的id，表示結果來自於這個查詢產生。如果是尖括號括起來的&l m,n>，與類似，也是乙個臨時表，表示這個結果來自於union查詢的id為m,n的結果集。
4）、type
依次從好到差：system，const，eq_ref，ref，fulltext，ref_or_null，unique_subquery，index_subquery，range，index_merge，index，all，除了all之外，其他的type都可以使用到索引，除了index_merge之外，其他的type只可以用到乙個索引
5）、possible_keys
查詢可能使用到的索引都會在這裡列出來
6）、key
查詢真正使用到的索引，select_type為index_merge時，這裡可能出現兩個以上的索引，其他的select_type這裡只會出現乙個。
7）、key_len
用於處理查詢的索引長度，如果是單列索引，那就整個索引長kfwcs度算進去，如果是多列索引，那麼查詢不一定都能使用到所有的列，具體使用到了多少個列的索引，這裡就會計算進去，沒有使用到的列，這裡不會計算進去。留意下這個列的值，算一下你的多列索引總長度就知道有沒有使用到所有的列了。要注意，mysql的icp特性使用到的索引不會計入其中。另外，key_len只計算where條件用到的索引長度，而排序和分組就算用到了索引，也不會計算到key_len中。
8）、ref
如果是使用的常數等值查詢，這裡會顯示const，如果是連線查詢，被驅動表的執行計畫這裡會顯示驅動表的關聯字段，如果是條件使用了表示式或者函式，或者條件列發生了內部隱式轉換，這裡可能顯示為func
9）、rows
這裡是執行計畫中估算的掃瞄行數，不是精確值
10）、extra
這個列可以顯示的資訊非常多，有幾十種，常用的有
除了這些之外，還有很多查詢資料字典庫，執行計畫過程中就發現不可能存在結果的一些提示資訊
11）、filtered
使用explain extended時會出現這個列，5.7之後的版本預設就有這個字段，不需要使用explain extended了。這個字段表示儲存引擎返回的資料在server層過濾後，剩下多少滿足查詢的記錄數量的比例，注意是百分比，不是具體記錄數。
本文標題: mysql如何基於explain關鍵字優化索引功能
本文位址:
MySQL學習14 查詢分析器explain
分析出表的讀取順序 資料讀取操作的操作型別 哪些索引可以使用 哪些索引被實際使用 表之間的引用 每張表有多少行被優化器查詢。引數描述 id執行select子句或操作表的順序 select type 查詢的型別，如 primary subquery derived union等 table 當前行使用...
基於docker安裝MySQL
為了更好的管理，打算把mysql redis等服務放在虛擬機器中統一部署，這樣不會因為這些服務的問題影響到系統本身。前段時間正好在看docker相關的內容，打算在虛擬機器中通過docker來使用mysql等服務。這次先記錄安裝mysql的過程。yum y install docker 複製 dock...
Hive 如何基於分割槽優化
最近一直做系統優化，但從建模的角度今天有個小優化，原理比較簡單，效果可能不是很大，但很有意思。這種優化的好處是不用改變sql 對使用者是透明的。所以分享下。由於hive在檔案基礎上，而會全部掃乙個分割槽裡面的內容。hive表的概念是基於hadoop的檔案系統hdfs，表其實是分布式檔案裡面的乙個檔案...