Mysql的儲存引擎和索引

標籤：操作   分享   返回   移動   通過   組成   索引   mysq   logs   

　2 Mysql的儲存引擎和索引

　　可以說資料庫必須有索引，沒有索引則檢索過程變成了順序尋找，O(n)的時間複雜度幾乎是不能忍受的。我們非常容易想象出一個只有單關鍵字組成的表如何使用B+樹進行索引，只要將關鍵字儲存到樹的節點即可。當資料庫一條記錄裡包含多個欄位時，一棵B+樹就只能儲存主鍵，如果檢索的是非主鍵欄位，則主鍵索引失去作用，又變成順序尋找了。這時應該在第二個要檢索的列上建立第二套索引。  這個索引由獨立的B+樹來組織。有兩種常見的方法可以解決多個B+樹訪問同一套表資料的問題，一種叫做聚簇索引（clustered index ），一種叫做非聚簇索引（secondary index）。這兩個名字雖然都叫做索引，但這並不是一種單獨的索引類型，而是一種資料存放區方式。對於聚簇索引儲存來說，行資料和主鍵B+樹儲存在一起，輔助鍵B+樹只儲存輔助鍵和主鍵，主鍵和非主鍵B+樹幾乎是兩種類型的樹。對於非聚簇索引儲存來說，主鍵B+樹在葉子節點儲存指向真正資料行的指標，而非主鍵。

　　InnoDB使用的是聚簇索引，將主鍵組織到一棵B+樹中，而行資料就儲存在葉子節點上，若使用"where id = 14"這樣的條件尋找主鍵，則按照B+樹的檢索演算法即可尋找到對應的分葉節點，之後獲得行資料。若對Name列進行條件搜尋，則需要兩個步驟：第一步在輔助索引B+樹中檢索Name，到達其葉子節點擷取對應的主鍵。第二步使用主鍵在主索引B+樹種再執行一次B+樹檢索操作，最終到達葉子節點即可擷取整行資料。

　　MyISM使用的是非聚簇索引，非聚簇索引的兩棵B+樹看上去沒什麼不同，節點的結構完全一致只是儲存的內容不同而已，主鍵索引B+樹的節點儲存了主鍵，輔助鍵索引B+樹儲存了輔助鍵。表資料存放區在獨立的地方，這兩顆B+樹的葉子節點都使用一個地址指向真正的表資料，對於表資料來說，這兩個鍵沒有任何差別。由於索引樹是獨立的，通過輔助鍵檢索無需訪問主鍵的索引樹。

　　為了更形象說明這兩種索引的區別，我們假想一個表如儲存了4行資料。其中Id作為主索引，Name作為輔助索引。圖示清晰的顯示了聚簇索引和非聚簇索引的差異。

 

 

　　我們重點關注聚簇索引，看上去聚簇索引的效率明顯要低於非聚簇索引，因為每次使用輔助索引檢索都要經過兩次B+樹尋找，這不是多此一舉嗎？聚簇索引的優勢在哪？

　　1 由於行資料和葉子節點儲存在一起，這樣主鍵和行資料是一起被載入記憶體的，找到葉子節點就可以立刻將行資料返回了，如果按照主鍵Id來組織資料，獲得資料更快。

　　2 輔助索引使用主鍵作為"指標" 而不是使用地址值作為指標的好處是，減少了當出現行移動或者資料頁分裂時輔助索引的維護工作，使用主索引值當作指標會讓輔助索引佔用更多的空間，換來的好處是InnoDB在移動行時無須更新輔助索引中的這個"指標"。也就是說行的位置（實現中通過16K的Page來定位，後面會涉及）會隨著資料庫裡資料的修改而發生變化（前面的B+樹節點分裂以及Page的分裂），使用聚簇索引就可以保證不管這個主鍵B+樹的節點如何變化，輔助索引樹都不受影響。

Mysql的儲存引擎和索引