聚集索引
上次我們講到了主鍵的索引,我們可以執行一下sql語句
explain select * from t_user where a = 1
我們可以看到這條sql走的是主鍵的索引，而在mysql的innodb中，主鍵索引則是聚集索引，資料的物理順序與鍵值的邏輯（索引）順序相同，其實就是說主鍵索引跟其他列的資料是存在一起的。
並且我們可以看到key_len,當前的長度是4，一般，key_len是等於所以列型別的位元組長度，因為我們這條sql執行的時候是走了乙個主鍵的索引，而主鍵是乙個int型別，乙個int型別是佔4個位元組，那麼長度就為4。那麼我們可以再驗證一下：
alter table t_user add index (b,c,e)
;
explain select * from t_user where b =
3 and d =
1
因為此時b是索引而d不是索引，所以執行的時候，會有4個位元組，又因為b是is null的所以會多占用乙個位元組。
現在我們將b設計為is not null，再次執行，此時的key_len就為4。
那麼建立索引的本質又是什麼呢，其實就是建立要給b+樹的資料結構，跟我們前面所講的主鍵索引是一樣的， 建立主鍵索引，其實就是按主鍵排序，然後做乙個b+樹的資料結構，那麼現在將字段b,c,e建立了索引，其實就是給b，c，e欄位建立乙個b+樹，索引之所以能夠快速查詢，是因為建立索引的字段進行了排序，也就是說，建立了b欄位作為索引就會給b欄位的列值進行乙個排序的操作。
主鍵只有乙個字段，排序就相對簡單，只需要對主鍵進行排序，而b,c,e三個欄位要進行排序，規則其實就是先比較b的大小，如果b的字段值大小相等，那麼就比較c的字段，然後按照此規則對資料進行排序。
非聚集索引
按照之前的組合規則
我們大概知道，對bce欄位進行排序之後的資料結構大概是這樣
那麼當我們要查詢a=3,b=1,e=b的時候，我們就可以直接定位到第一頁的資料的第二條，但是我們可以看到當前這裡只儲存了4個字段的值，而我們要找的是全部欄位的值，當然mysql不可能把所有列的值都存在葉子節點中，於是就在葉子節點中儲存了該列的主鍵。
那麼我們就可以利用這個元件找到一整列的資料，那麼自然就有下面的對應關係。
最左字首
當我們執行上面的sql語句的時候,我們都知道這條sql不會走索引,從key_len欄位中也可以看出,那麼為什麼沒有走索引呢,因為我們建立索引的時候是指定了b,c,e三個字段建立了索引,現在我們執行這條sql的時候,我們可以把他想像成 *1a 去到資料庫中查詢,那麼當我們這個值去我們下面這個圖查詢的時候
由於最左邊的字段是未知的 所以根本就不知道要從左邊的11a往下找還是從右邊的31c往下找,畢竟最左的索引的值無法確定,那麼就會造成乙個全表掃瞄。達不到索引的意義。
mysql底層 索引
mysql只是乙個應用軟體，不能直接讀取磁碟上的資料，當我們需要讀取某條資料的時候，mysql呼叫核心的乙個函式，告訴核心我要讀取某個資料，核心驅動磁柱磁頭去讀取資料，讀取資料之後怎麼返回裡，其實是把資料寫到記憶體中了 這個記憶體只是核心記憶體，並不是mysql記憶體 接下來再把資料copy到mys...
mysql索引底層
資料結構 二叉樹 從父節點開始，大的往右，小的往左，當有序的增長就變成了單邊增長，就會對效能沒什麼提公升，不適合 紅黑樹 二叉樹的平衡版，通過自旋等方式實現平衡 當資料很多時，紅黑樹的高度就變得很高，查詢一次需要多次的io不適合大資料查詢 b樹和b 樹 乙個節點都可以存多個元素 多叉樹 以有序的方式...
mysql 索引 層數 mysql 索引底層
hash索引o 1 b 樹索引 o logn 為什麼紅黑樹出現了，因為防止某些情況下二叉排序樹退化為鍊錶 誕生了二叉排序平衡樹 樹的效能取決於樹的高度 為什麼db要用m路b樹，為了再降低樹的高度，減少db 磁碟io 次數，如果在記憶體中，紅黑樹效率更高 為什麼m不能無限大，因為會退化成有序陣列，無法...