1:索引類型
索引： 作用快速查詢；
節點第1層 ， 2的0次方
節點第1層 ， 2的1次方
節點第3層 ， 2的2次方
節點第4層 ， 2的3次方
節點第5層 ， 2的4次方
.。。。
。。。
。。。
節點第31層 ， 2的32次方
加起來 42億
也就是說 42 億個數字 最多查 32 次就可以了
普通查詢要查21億次
這就是—–》 B-tree索引
注: 名叫btree索引,大的方面看,都用的平衡樹,但具體的實現上,各引擎稍有不同,
比如,嚴格的說,NDB引擎,使用的是T-tree
Myisam,innodb中,默認用B-tree索引
但抽象一下—B-tree系統,可理解為”排好序的快速查找結構”.?
1.2 hash索引 彈簧哈哈哈哈。。。尼瑪尼瑪。。。
在memory表里,默認是hash索引,
hash的理論查詢時間復雜度為O(1)
疑問: 既然hash的查找如此高效,為什么不都用hash索引?
答:?
1:hash函數計算后的結果,是隨機的,如果是在磁盤上放置數據,
用 算法。。。。。
比主鍵為id為例,那么隨著id的增長,
id對應的行,在磁盤上隨機放置.散落的無規律！！
散列算法 分配磁盤空間毫無規律可言！！！
2: 無法對范圍查詢進行優化. 3:無法利用前綴索引.?
比如 在btree中, field列的值“hellopworld”,并加索引
查詢 xx=helloword,自然可以利用索引, xx=hello,也可以利用索引.
(左前綴索引)?
因為hash(‘helloword’),和hash(‘hello’),兩者的關系仍為隨機
4: 排序也無法優化.
5: 必須回行.就是說 通過索引拿到數據位置,必須回到表中取數據?
——》回行查找 就說只是個字典的目錄 必須再去實際翻頁
2: btree索引的常見誤區
2.1 在where條件常用的列上都加上索引
例: where cat_id=3 and price>100 ; //查詢第3個欄目,100元以上的商品
誤: cat_id上,和, price上都加上索引.
錯: 只能用上cat_id或Price索引,因為是獨立的索引,同時只能用上1個.
alter table add index(cat_id)
alter table add index(price)
alter table add index(goods_id) —————————同時只能用一個 所以。。。。 聯合索引 把多個列看成整體的值
index（cat_id ,goods_name, price） ————————— 把多個列看成整體的值
2.2 在多列上建立索引后,查詢哪個列,索引都將發揮作用
誤: 多列索引上,索引發揮作用,需要滿足左前綴要求.
///做前綴要求
以 index(a,b,c) 為例,(注意和順序有關)
語句
? ?索引是否發揮作用
? ?
Where a=3
? ?是,只使用了a列
? ?
Where a=3 and b=5?
? ?是,使用了a,b列
? ?
Where a=3 and b=5 and c=4
? ?是,使用了abc
? ?
Where b=3 / where c=4
? ?否
? ?
Where a=3 and c=4
? ?a列能發揮索引,c不能
? ?
Where a=3 and b>10 and c=7
? ?A能利用,b能利用, C不能利用
? ?
同上,where a=3 and b like ‘xxxx%’ and c=7
? ?A能用,B能用,C不能用
? ?
為便于理解, 假設ABC各10米長的木板,河面寬30米.
精確匹配,則木板長10米,
Like,左前綴及范圍查詢,則木板長5米,
自己拼接一下,能否過河對岸,就知道索引能否利用上.
如上例中, where a=3 and b>10, and c=7,
A板長10米,A列索引發揮作用
A板正常接B板, B板索引發揮作用
B板短了,接不到C板,
C列的索引不發揮作用.
?以上就是mysql 優化（2）索引優化策略的內容，更多相關內容請關注PHP中文網（www.php.cn）！
