索引:加速查詢的數據結構
一、索引設計原則
1. 經常查詢的字段,建議創建索引;
2. 索引不是越多越好:維護索引結構會佔用磁盤空間(每個索引是一個單獨的存儲結構)、影響增刪查改的性能(查:生成執行計劃時要考慮各個索引;可能用不到最佳索引; 增刪改:要維護每個索引的結構);
3. 經常更新的表不要太多索引: 數據更新時會調整索引,消耗系統資源;
4. 數據量小的表不要創建索引、區分度低的字段不要建立索引: 索引起不到優化效果,維護索引結構反而消耗系統資源
5. 字段具有唯一性時,創建唯一索引能提高查詢速度;
6. 頻繁排列分組(group by、order by)的字段,如果待排序字段有多個,可以建組合索引
二、索引匹配規則
1. 最左前綴匹配原則,否則不會命中索引 (B+樹的存儲結構,從左向右匹配索引,如果是聯合索引則按建立聯合索引的順序存放,且sql中)
2. like,如果以%開頭,不會命中索引 (where name like "%張") (因爲索引是從左向右匹配)
3. 負向條件(!= / not in / not exists)查詢不會用到索引 ==> 實際跑了一下發現用到了索引!
4. 在屬性上進行計算不能命中索引(where id*3=3000,確實沒走到)
三、B樹和B+樹
其他結構:順序查找:O(n)
hash索引:無法滿足範圍查找、模糊查找。
二叉樹、紅黑樹:O(h) 大量數據時樹很高,IO次數多導致查找慢; 相鄰數據無指針關聯,不能範圍查找。
B樹的特點:
1. 所有節點都可以存儲數據。每個節點有多個關鍵字,每個關鍵字都是一個二元數組:[key,data],key爲索引字段,value爲除索引外其他字段。
2. 一層層查找,本層找到數據,或者往對應區間下層的指針指向的節點遞歸查找。
3. 缺點:數據增刪時會破壞B樹的結構,需要對樹進行分裂、合併、轉移等操作保持結構,IO頻繁;
區間查找時可能會往返上下層遍歷,IO頻繁;
各層節點都存儲數據,所以每頁能存的關鍵字變少,樹的深度增加。
B+樹的特點:
1. 非葉子節點不存data,只存索引key。只有葉子節點才存key+data
2. 在葉子節點的尾巴上增加下一個相鄰葉子節點的頭結點指針(雙向鏈表),把所有數據串起來。
3. 三層的B+樹能存儲大約2000萬條數據(即只需要3次IO):InnoDB的索引節點大小默認16k,前兩層只存索引(假設主鍵id用bigint,佔8字節)+該區間的下層指針(6字節),第三層存索引+完整記錄,假設每條記錄佔1k,一個節點存16條數據,即1170*1170*16。