索引的出現為了查詢提高查詢速度,順序查詢速度過慢,所以索引的儲存方式對與查詢有很大的影響
1 二叉樹
使用二叉樹作為資料結構,相對於陣列這種順序結構是快了很多,利用二叉樹的特性右子節點比父節點大,左子節點比父節點小的遠離進行查詢,但是當索引資料出現順序值,例如1,2,3,4,5,6這樣的情況,就會造成二叉樹失去了平衡,造成一側節點大,所以是不合適的
2 紅黑樹
紅黑樹相對比二叉樹,就是對失去平衡的二叉樹做了平衡處理,當一側節點出現過多的時候,會進行左旋和右旋進行變化保持數的平衡,但是當資料量過大,節點一側還是會出現失去平衡,查詢次數會增多,紅黑樹這種資料結構還是不適合,資料量小的話還行
3 b-tree和b+tree
b-tree是對紅黑樹進行了優化,根據紅黑樹可以看出,如果樹的深度太大,就會造成多次查詢,多次io,查詢很慢,如果樹的深度為2或者3 那樣豈不是很快,所有b-tree利用這一點,改進了紅黑樹,增加了節點的記憶體,每個節點可以橫向擴充套件,掛多個值,沒記錯的話,子節點可以儲存為16k的索引。b-tree的非子節點儲存的的是索引值和下乙個索引的磁碟位址,一般我們設定樹的深度為2~4之間,控制了樹的深度,每個節點大概可以儲存1176個索引,按照樹的深度為3來計算,子節點可以儲存大約16k的大小,1176*1176*12=22127616,也就是說可以儲存2000萬個索引值,最後io查詢兩次可以定位到資料,一般根節點的索引值是在記憶體中,這樣在記憶體中進行比對是很快的。mysql儲存引擎有個叫做mysam,可以看到檔案在磁碟中儲存和innodb是不一樣,他有三個檔案,乙個是表的結構,乙個是表的資料行,乙個就是索引,但是innodb只有兩個檔案,也即是聚集索引,將索引和資料儲存在乙個檔案中,因為innodb索引的子節點不是資料所在的位址而是資料,這也就是b+tree,相比來說,innodb比mysam少了一次io查詢,畢竟mysam是非聚集索引(索引和資料存在兩個檔案內)
4 為什麼使用innodb引擎建議簡歷索引,且索引為整形
innodb是將資料儲存為b+tree的資料結構的檔案,葉子節點為順序型別的排序,如果新增元素不按照自然順序就會造成葉子節點的移動操作,很耗時的,且很可能會造成葉子節點的裂變導致樹的結構發生改變,也就是樹的深度會加深。
總結如下:
innodb引擎表是基於b+樹的索引組織表(iot); 每個表都需要有乙個聚集索引(clustered index);
所有的行記錄都儲存在b+樹的葉子節點(leaf pages of the tree); 基於聚集索引的增、刪、改、查的效率相對是最高的;
如果我們定義了主鍵(primary key),那麼innodb會選擇其作為聚集索引;
如果沒有顯式定義主鍵,則innodb會選擇第乙個不包含有null值的唯一索引作為主鍵索引;
如果也沒有這樣的唯一索引,則innodb會選擇內建6位元組長的rowid作為隱含的聚集索引(rowid隨著行記錄的寫入而主鍵遞增,這個rowid不像oracle的rowid那樣可引用,是隱含的)。
索引學習筆記
一 index屬性介紹 field.store.yes或者no 儲存域選項 yes 將會儲存域值,原始字串的值會儲存在索引中,以此可以進行相應的恢復操作,對於主鍵,標題可以是這種方式儲存 no 不會儲存域值,通常與index.anaylized合起來使用,索引一些如文章正文等不需要恢復的文件 此時內...
索引 學習筆記
tablespace 表空間可以省略 b樹索引 反向鍵索引 函式索引 位圖索引 刪除索引 b樹索引 示例一 建立一張表並使用pl sql的資料生成器匯入10萬條記錄 建立儲戶表 create table depositor actid integer notnull identify integer...
索引 學習筆記
tablespace 表空間可以省略 b樹索引 反向鍵索引 函式索引 位圖索引 刪除索引 b樹索引 示例一 建立一張表並使用pl sql的資料生成器匯入10萬條記錄 建立儲戶表 create table depositor actid integer notnull identify integer...