概述
優化索引
在MySQL初階的課程中已經介紹了索引,我們知道InnoDB存儲引擎使?B+樹作為索引默認的數據結構來組織數據,為頻繁查詢的列建?索引可以有效的提升查詢效率,那么如何利?索引編寫出?效的SQL查詢語句?以及如何分析某個查詢是否?到了索引?當前的索引還有沒有優化的空間?下?我們來討論關于索引和優化相關的問題。
關于mysql索引的理解,除了自動創建的主鍵索引是將所有的字段都放在索引樹當中,其他的索引都只有索引字段和主鍵,那么其他的索引檢索到要查詢的數據后還是需要根據存儲的主鍵id去主鍵索引去查找全部的數據的
使用主鍵查詢
使用非索引查詢
壓測工具
執行計劃EXPLAIN
執行計劃并不會真的去執行sql語句。
執行計劃字段說明
id列
select_type列
table列
partitions列
type列
possible_keys列
key列
key_len列
ref列
rows列和filtered列
extra列
type列詳解
system
const
eq_ref
在多表鏈接的場景,兩個唯一值一一對應相互關聯的場景。
ref
fulltext
ref_or_null
index_merge
unique_subquery和index_subquery
range
index
all
只有單個查詢當中沒有使用的列才算是全表掃描,先使用索引查詢后再次查詢的不能算。
extra列詳解
USing Temporary
Using filesort
當內存不足的時候就會申請臨時文件,這是比內存更嚴重的情況,io效率極低。
使用了索引來進行排序就不會發生這種情況了。
usingWhere
如果通過了索引樹的話,那進行的就不是全表掃描,而掃描的是索引樹。
using index
表示出現了索引覆蓋,效率極高。
索引覆蓋
回表查詢
優化Select
where字句優化
高效查詢示例
范圍優化
優化器執行過程
多部索引范圍訪問
索引下推
外連接優化
is null優化
查詢b列有索引走了索引,查詢c列沒有索引就全表掃描,也有可能走了索引還是全表掃描
order by優化
group by優化
索引失效
沒有遵守最左原則
where中有or且其中一個條件沒有索引
因為or條件除非第一個條件滿足了,不然基本上是要找的,與其走一次索引加一次全表掃描,不如只走一次全表掃描。