BTREE的優勢？

Question

我創建沒有「USING BTREE」子句的索引。使用BTREE索引有什麼優勢嗎？

CREATE INDEX `SomeName` USING BTREE ON `tbl_Name`(`column_name`); 

Answer 1

BTREE是默認的索引方法。你可以放心地省略它。

Answer 2

這取決於您正在使用的存儲引擎。對於大多數情況，BTREE是默認的，因此指定它並不會真正改變任何內容。對於諸如MEMORY/HEAP和NDB的存儲引擎，缺省情況下默認使用HASH索引。

的更多信息，可以發現here.

無論B樹或哈希索引是你有利，從性能的角度取決於數據，以及如何你訪問它。如果您知道您的查詢將準確定位到一行或分散的單個行，那麼HASH索引可能會很有用。除此之外，我通常更喜歡BTREE索引，因爲數據是排序的，因此可以進行範圍查詢以及返回多行的效率更高的查詢。

Answer 3

首先，根據所使用的存儲引擎，您可能沒有選擇（例如，InnoDB專門爲其索引使用BTREE）。

此外，BTREE是大多數存儲引擎的默認索引類型。

現在...有些情況下，使用替代索引類型可能會導致性能提高。有（相對罕見的情況下）HASH索引可能有所幫助。請注意，當創建HASH索引時，還會生成一個BTREE索引。部分原因在於散列索引只能解析相等謂詞。 （例如WHERE Price> 12.0的條件不能由散列索引處理）。

簡而言之：保持使用BTREE，無論是隱式（如果BTREE是所用存儲的缺省值），還是顯式地使用。瞭解其他類型的指數，以便您瞭解它們是否需要。

編輯：（在搜索情況下，當可以使用替代的索引類型）
有效的情況下是相當爲RTREE索引直線前進。這些僅在"SPATIAL" databases的上下文（即，包括地理位置上下文，諸如GIS模型中的點和其他對象的數據庫）的情況下用MySQL支持）。

散列索引是更通用的（不侷限於特定的應用或數據類型），和一個一般可以按照哈希的一個直觀的認識得到一個提示，當這些可能跑贏老，但忠實的BTREE。如前所述，這意味着列通常以相同的謂詞搜索。我猜測相對較短的查找表等可能會受益，這取決於MySQL中的有效實現。

Answer 4

搜索平衡樹意味着所有的葉子都在相同的深度。沒有跑道指針的開銷。的確，更大的B樹可以保證必須檢索少量的節點才能找到給定的密鑰。例如，一個10,000,000個密鑰的B樹（每個節點有50個密鑰）從不需要檢索多於4個節點來查找任何密鑰。 B樹是一種索引的特殊數據結構格式，允許快速訪問索引中的數據。該數據結構的一個屬性是索引總是平衡的。這意味着最低級別的每個節點是等距的從最頂端的節點或樹的根節點開始，並且索引的每一側具有相同數量的節點。最低級別處的節點被稱爲葉節點。所有其他節點被稱爲分支節點。分支點到其他分支或葉節點。葉節點存儲索引列的值和指向具有這些值的不同行的rowid。 實際分佈將取決於B樹中每個值範圍內的數據值的數量，總體目標是減少爲達到特定值而必須穿過的必需水平的數量。 B樹結構的優點是：

1. 所有葉塊的深度相同（值的數量）。
2. B樹的高度通常很小。在某些情況下，根節點是唯一的葉節點，高度爲1.當表中插入更多行時，索引必須增長以適應此但即使在超過100萬行的表中，B樹idex的高度通常也是3.在最大的表中，高度可能只有4。這意味着即使是最大的表，也只需要4塊找到你正在查找的行的rowid，這非常有效。
3. 在隨機輸入數據的情況下，B樹自動保持平衡。實際上，無論輸入什麼數據，B樹都保持平衡。
4. B樹索引的所有塊都有四分之三滿（平均），允許插入而沒有分割樹。 5.B-tree爲所有類型的選擇提供出色的性能。 6.插入，更新和刪除在B樹結構中往往是有效的。 7.即使表格從小到大，B樹的性能仍然保持最佳狀態。

Answer 5

簡化的答案是，如果您的SQL在該字段上使用LIKE語句，那麼使用BTREE索引應該會超過散列索引。如果您對該字段使用等於（=）的語句，則使用散列索引。