mysql的索引方法btree和hash的區別
阿新 • • 發佈：2019-02-03
2. B-Tree索引
B-Tree 索引是 MySQL 資料庫中使用最為頻繁的索引型別，除了 Archive 儲存引擎之外的其他所有的儲存引擎都支援 B-Tree 索引。不僅僅在 MySQL 中是如此，實際上在其他的很多資料庫管理系統中B-Tree 索引也同樣是作為最主要的索引型別，這主要是因為 B-Tree 索引的儲存結構在資料庫的資料檢 索中有非常優異的表現。
一般來說， MySQL 中的 B-Tree 索引的物理檔案大多都是以 Balance Tree 的結構來儲存的，也就是所有實際需要的資料都存放於 Tree 的 Leaf Node ，而且到任何一個 Leaf Node 的最短路徑的長度都是完全相同的，所以我們大家都稱之為 B-Tree 索引當然，可能各種資料庫（或 MySQL 的各種儲存引擎）在存放自己的 B-Tree 索引的時候會對儲存結構稍作改造。如 Innodb 儲存引擎的 B-Tree 索引實際使用的儲存結構實際上是 B+Tree ，也就是在 B-Tree 資料結構的基礎上做了很小的改造，在每一個
Leaf Node 上面出了存放索引鍵的相關資訊之外，還儲存了指向與該 Leaf Node 相鄰的後一個 LeafNode 的指標資訊，這主要是為了加快檢索多個相鄰 Leaf Node 的效率考慮。
在 Innodb 儲存引擎中，存在兩種不同形式的索引，一種是 Cluster 形式的主鍵索引（ Primary Key ），另外一種則是和其他儲存引擎（如 MyISAM 儲存引擎）存放形式基本相同的普通 B-Tree 索引，這種索引在 Innodb 儲存引擎中被稱為 Secondary Index 。下面我們通過圖示來針對這兩種索引的存放
形式做一個比較。
圖示中左邊為 Clustered 形式存放的 Primary Key ，右側則為普通的 B-Tree 索引。兩種 Root Node 和 Branch Nodes 方面都還是完全一樣的。而 Leaf Nodes 就出現差異了。在 Prim中， Leaf Nodes 存放的是表的實際資料，不僅僅包括主鍵欄位的資料，還包括其他欄位的資料據以主鍵值有序的排列。而 Secondary Index 則和其他普通的 B-Tree 索引沒有太大的差異，Leaf Nodes 出了存放索引鍵 的相關資訊外，還存放了 Innodb 的主鍵值。
所以，在 Innodb 中如果通過主鍵來訪問資料效率是非常高的，而如果是通過 Secondary Index 來訪問資料的話， Innodb 首先通過 Secondary Index 的相關資訊，通過相應的索引鍵檢索到 Leaf Node之後，需要再通過 Leaf Node 中存放的主鍵值再通過主鍵索引來獲取相應的資料行。MyISAM 儲存引擎的主鍵索引和非主鍵索引差別很小，只不過是主鍵索引的索引鍵是一個唯一且非空 的鍵而已。而且 MyISAM 儲存引擎的索引和 Innodb 的 Secondary Index 的儲存結構也基本相同，主要的區別只是 MyISAM 儲存引擎在 Leaf Nodes 上面出了存放索引鍵資訊之外，再存放能直接定位到 MyISAM 資料檔案中相應的資料行的資訊（如 Row Number ），但並不會存放主鍵的鍵值資訊
B-Tree 索引是 MySQL 資料庫中使用最為頻繁的索引型別，除了 Archive 儲存引擎之外的其他所有的儲存引擎都支援 B-Tree 索引。不僅僅在 MySQL 中是如此，實際上在其他的很多資料庫管理系統中B-Tree 索引也同樣是作為最主要的索引型別，這主要是因為 B-Tree 索引的儲存結構在資料庫的資料檢 索中有非常優異的表現。
一般來說， MySQL 中的 B-Tree 索引的物理檔案大多都是以 Balance Tree 的結構來儲存的，也就是所有實際需要的資料都存放於 Tree 的 Leaf Node ，而且到任何一個 Leaf Node 的最短路徑的長度都是完全相同的，所以我們大家都稱之為 B-Tree 索引當然，可能各種資料庫（或 MySQL 的各種儲存引擎）在存放自己的 B-Tree 索引的時候會對儲存結構稍作改造。如 Innodb 儲存引擎的 B-Tree 索引實際使用的儲存結構實際上是 B+Tree ，也就是在 B-Tree 資料結構的基礎上做了很小的改造，在每一個
Leaf Node 上面出了存放索引鍵的相關資訊之外，還儲存了指向與該 Leaf Node 相鄰的後一個 LeafNode 的指標資訊，這主要是為了加快檢索多個相鄰 Leaf Node 的效率考慮。
在 Innodb 儲存引擎中，存在兩種不同形式的索引，一種是 Cluster 形式的主鍵索引（ Primary Key ），另外一種則是和其他儲存引擎（如 MyISAM 儲存引擎）存放形式基本相同的普通 B-Tree 索引，這種索引在 Innodb 儲存引擎中被稱為 Secondary Index 。下面我們通過圖示來針對這兩種索引的存放
形式做一個比較。
圖示中左邊為 Clustered 形式存放的 Primary Key ，右側則為普通的 B-Tree 索引。兩種 Root Node 和 Branch Nodes 方面都還是完全一樣的。而 Leaf Nodes 就出現差異了。在 Prim中， Leaf Nodes 存放的是表的實際資料，不僅僅包括主鍵欄位的資料，還包括其他欄位的資料據以主鍵值有序的排列。而 Secondary Index 則和其他普通的 B-Tree 索引沒有太大的差異，Leaf Nodes 出了存放索引鍵 的相關資訊外，還存放了 Innodb 的主鍵值。
所以，在 Innodb 中如果通過主鍵來訪問資料效率是非常高的，而如果是通過 Secondary Index 來訪問資料的話， Innodb 首先通過 Secondary Index 的相關資訊，通過相應的索引鍵檢索到 Leaf Node之後，需要再通過 Leaf Node 中存放的主鍵值再通過主鍵索引來獲取相應的資料行。MyISAM 儲存引擎的主鍵索引和非主鍵索引差別很小，只不過是主鍵索引的索引鍵是一個唯一且非空 的鍵而已。而且 MyISAM 儲存引擎的索引和 Innodb 的 Secondary Index 的儲存結構也基本相同，主要的區別只是 MyISAM 儲存引擎在 Leaf Nodes 上面出了存放索引鍵資訊之外，再存放能直接定位到 MyISAM 資料檔案中相應的資料行的資訊（如 Row Number ），但並不會存放主鍵的鍵值資訊