MySQL中like查询是否会使用索引
生活随笔
收集整理的這篇文章主要介紹了
MySQL中like查询是否会使用索引
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
MySQL中l(wèi)ike查詢使用索引
- explain查看執(zhí)行計劃
- 實驗過程
- Like 不走索引的優(yōu)化
explain查看執(zhí)行計劃
首先介紹一下mysql explain的各項內容:
| 1 | id | 查詢的ID | ID相同從上往下執(zhí)行,ID不同,越大越先執(zhí)行 |
| 2 | select_type | 查詢類型 | SIMPLE 簡單查詢 PRIMARY 最外層的查詢 Union SUBQUERY 子查詢。 還有很多類型可以看官方文檔 https://dev.mysql.com/doc/refman/5.6/en/explain-output.html |
| 3 | table | 表 | |
| 4 | partitions | 匹配分區(qū) | |
| 5 | type | 連接類型 | system:表為空或只有一行 const:查詢結果就只有一行,這樣msql優(yōu)化器就能把這一行當成常量處理,一般只有用主鍵/唯一索引查的時候出現 eq_ref:在當前表中只能找到一行與前面的查詢結果一一匹配,一般是用主鍵或惟一索引進行連接,用=符號 ref:在當前表中可以找到多行與前面的查詢結果一一匹配,一般是用主鍵的最左前綴或非唯一索引,用=, > , < 符號 full_text:用fulltext索引時使用 ref_null:和 ref很像,就是多搜索一個null條件 index_merge: 用到了不止一個索引,mysql做了優(yōu)化 range:用于范圍查詢,包括like。Index:索引全表掃描;1.覆蓋索引,只需要掃描全部索引,無需回表; ALL:全表掃描 |
| 6 | possible_keys | 可能選擇的索引 | |
| 7 | key | 實際選擇的索引 | 實際選擇的索引可能并不在possible_keys中,(這種情況是mysql發(fā)現你查的是個覆蓋索引,掃描索引比掃描全表要好) |
| 8 | key_len | 選擇的索引的長度 | 主要是聯(lián)合索引看看用到了多少 |
| 9 | ref | 與索引相比較的列 | const:用的常數 func:用的函數 |
| 10 | rows | 預估掃描行數 | |
| 11 | filtered | 查詢條件過濾后占的百分比 | 只對index和all類型的查詢生效,其他類型都為100%,可以看下這個文章http://blog.chinaunix.net/uid-20726500-id-5573764.html |
| 12 | Extra | 額外信息 | 介紹 |
實驗過程
- like xxx%查詢
查詢結果
可以看出ID為1 沒什么好說的,然后是simple的查詢,用到的表為location,分區(qū)為null,連接的類型是range(因為是用like查詢的),possible_keys為可以使用的location_path列上的索引,最終使用的也是這個key,key_length = 1020,這個是怎么算的呢?
先看下表的列的類型和字符集:
Location_path這一列是char(255),uft8mb4_0900_ai_ci正好對于每個字符用4個字節(jié)存儲:4*255 = 1020; 如果loation_path 允許為null,則還需要多一個字節(jié)存儲null,key_length會為1021,使用了索引進行查詢,掃描行數為6行,使用了索引。
- like %xxx查詢
這個則沒有使用索引
- like %xxx%查詢
這個也沒有使用索引查詢
如果前綴為%,索引不知道應該如何匹配,所以不會用到
發(fā)現使用了索引,但是過濾的行數還是7行,possible_keys為空,也就是估計沒用索引,但是實際查詢時候發(fā)現是覆蓋索引的查詢,所以用上了。
Like 不走索引的優(yōu)化
benchmark對比如下:看起來查不了多少,基本上一樣(也可能和數據量有關系,畢竟表里面就幾條數據)
總結
以上是生活随笔為你收集整理的MySQL中like查询是否会使用索引的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 三维动画--Blender软件介绍
- 下一篇: 新年许愿