mysql 優化（2）索引優化策略

1:索引類型

索引： 作用快速查詢；

節點第1層，2的0次方

節點第1層，2的1次方

節點第3層，2的233層次方

節點第4層， 2的3次方

節點第5層， 2的4次方

.。 。 。

。 。 。

。 。 。

節點第31層， 2的32次方

加起來42億

也就是說42 億個數字最多查32 次就可以了

普通查詢要查21億次
查32 次就可以了

普通查詢要查21億次



----》 B-tree索引

注: 名叫btree索引,大的方面看,都用的平衡樹,但具體的實現上,各引擎稍有不同,

比如,嚴格的說,NDB引擎,使用的是T-tree

Myisam,innodb中,預設用B-tree索引



但抽像一下---B-tree系統,可理解為」排好序的快速查找結構」. 



1.2 hash索引彈簧哈哈哈哈。 。 。尼瑪尼瑪。 。 。

在memory表裡,預設是hash索引,
hash的理論查詢時間複雜度為O(1)



疑問: 既然hash的查找如此高效,為什麼不都用hash索引?

疑問: 既然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) 為例,(注意力與順序有關)

語句

   索引是否發揮作用

了a列

   

Where a=3 and b=5 

   是,使用了a,b列

   
=Wh了3a,b列

   

=

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

   

   

為便於理解, 假設ABC各10米長的木板,河面寬30米.

精確匹配,則木板長10米,

Like,左前綴木板及範圍查詢,則木板長10米,

Like,左前木板及範圍查詢則木板長5米,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）！