InnoDB索引實現(xiàn)

         對于InnoDB存儲引擎的表，記錄默認會按一定順序保存，如果有明確定義的主鍵，則按照主鍵順序保存。如果沒有主鍵，但是有唯一索引，就按照唯一索引的順序保存。如果既沒有主鍵也沒有唯一索引，表中會自動生成一個內部列，按照這個列的順序保存。按照主鍵或內部列的訪問是最快的，索引InnoDB表盡量自己指定主鍵，當表中同時有幾個列都是唯一的，都可以作為主鍵的時候，要選擇最常作為訪問條件的列作為主鍵，提高查詢效率。另外，InnoDB表的普通索引都會保存主鍵的鍵值，這樣通過對索引加鎖就可以實現(xiàn)行級鎖。

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

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

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

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

聚簇索引優(yōu)點：

1 查詢速度更快：由于行數(shù)據(jù)和葉子節(jié)點存儲在一起，這樣主鍵和行數(shù)據(jù)是一起被載入內存的，找到葉子節(jié)點就可以立刻將行數(shù)據(jù)返回了，如果按照主鍵Id來組織數(shù)據(jù)，獲得數(shù)據(jù)更快。

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

InnoDB行鎖的實現(xiàn)：

InnoDB的行鎖是加在索引上的，實現(xiàn)過程如下：

1.按輔助索引檢索：行鎖加在輔助索引對應的列，并根據(jù)主鍵項找到主鍵索引加鎖。

如上圖，按name字段檢索name='Ellision'，Ellision索引列會加鎖，并在主鍵索引項14 加鎖。這樣當其他事務就無法訪問name='Ellision'列，也無法根據(jù)其他數(shù)據(jù)項訪問相應的數(shù)據(jù)列。