USING BTREE
我创建没有该子句的索引。使用BTREE索引有什么好处吗?
CREATE INDEX `SomeName` USING BTREE ON `tbl_Name`(`column_name`);
USING BTREE
我创建没有该子句的索引。使用BTREE索引有什么好处吗?
CREATE INDEX `SomeName` USING BTREE ON `tbl_Name`(`column_name`);
首先,根据使用的存储引擎,您可能别无选择(例如 InnoDB 专门使用 BTREE 作为其索引)。
此外,BTREE 是大多数存储引擎的默认索引类型。
现在...在某些情况下,使用替代索引类型可能会提高性能。在某些情况下(相对罕见的情况)哈希索引可能会有所帮助。请注意,当创建 HASH 索引时,也会生成 BTREE 索引。部分原因是哈希索引只能解析相等谓词。(哈希索引无法处理诸如 WHERE Price > 12.0 之类的条件)。
简而言之:继续使用 BTREE,无论是隐式(如果 BTREE 是所用存储的默认值),还是显式。了解其他类型的索引,以便了解它们是否需要。
编辑:(在搜索可能使用替代索引类型的情况下)对于RTREE索引
来说,这种情况实际上是相当直接的。只有在“空间”数据库的上下文中,MySQL 才支持这些,即包括地理位置上下文的数据库,例如 GIS 模型中的点和其他对象)。
HASH 索引更通用(不限于特定的应用程序或数据类型),通常可以根据对哈希的直观理解来获得关于何时这些可能优于旧但忠实的 BTREE 的提示。如前所述,这意味着通常使用相等谓词搜索列。我猜测相对较短的查找表等可能会受益,这取决于 MySQL 中的有效实现。
BTREE 是默认的索引方法。您可以放心地省略它。
这取决于您使用的存储引擎。对于大多数人来说,BTREE 是默认设置,因此指定它并不会真正改变任何东西。对于 MEMORY/HEAP 和 NDB 等存储引擎,默认使用 HASH 索引。
更多信息可以在这里找到。
从性能角度来看,B 树或 HASH 索引是否对您有利取决于数据以及您访问它的方式。如果您知道您的查询将只针对一行或分散的单个行,那么 HASH 索引可能会很有用。除此之外,我通常更喜欢 BTREE 索引,因为对数据进行了排序,从而使范围查询和返回多行的查询更有效率。
搜索平衡树意味着所有叶子都在相同的深度。没有跑道指针开销。事实上,即使是更大的 B 树也可以保证必须检索少量节点才能找到给定的键。例如,包含 10,000,000 个键且每个节点有 50 个键的 B 树永远不需要检索超过 4 个节点来找到任何键。B树是一种特殊的索引数据结构格式,允许快速访问索引中的数据。这种数据结构的一个属性是索引总是平衡的。这意味着最低级别的每个节点都是等距的从最顶层的节点或树的根节点开始。并且索引的每一侧都有相同数量的节点。最低级别的节点称为叶节点。所有其他节点称为分支节点。分支点到其他分支或叶节点。叶节点存储索引列的值和指向具有这些值的不同行的 rowid。实际分布将取决于 B 树中每个值范围内的数据值的数量,总体目标是减少为达到特定值而必须遍历的所需级别的数量。B树结构的优点是:
简化的答案是,如果您的 SQL 在该字段上使用 LIKE 语句,那么使用 BTREE 索引应该优于哈希索引。如果您对该字段使用等于 (=) 语句,请使用哈希索引。