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索引应该会超过散列索引。如果您对该字段使用等于（=）的语句，则使用散列索引。