在MySQL中，索引类型是b树，并且访问b树中的元素是以对数摊销时间O(log(n))。
另一方面，访问哈希表中的元素是在O(1)中。
为什么不使用哈希表而不是b树来访问数据库中的数据？
您只能通过哈希表中的主键访问元素。这比使用树算法（O(1)而不是log(n)）更快，但是你不能选择范围（x和y之间的所有内容）。树算法在Log(n)中支持这一点，而哈希索引可以导致全表扫描O(n)。哈希索引的常量开销通常也更大（这不是theta表示法的因素，但它仍然存在）。树算法通常更容易维护，随数据，规模等增长。
散列索引使用预定义的散列大小，因此您最终会得到一些存储对象的“存储桶”。这些对象再次循环，以便在此分区中找到正确的对象。
因此，如果您的尺寸较小，则对于小尺寸元件会产生大量开销，因此大尺寸会导致进一步扫描。
今天的哈希表算法通常可以缩放，但缩放可能效率低下。
确实存在可扩展的散列算法。不要问我这是怎么回事 - 对我来说这也是一个谜。 AFAIK是从可扩展复制发展而来的，其中重新散列并不容易。
它被称为RUSH - 可扩展散列下的复制，因此这些算法称为RUSH算法。
但是，与您的散列大小相比，您的索引可能超出了可容忍的大小，并且需要重新构建整个索引。通常这不是问题，但对于巨大的巨大数据库，这可能需要数天时间。
树算法的权衡很小，它们几乎适用于所有用例，因此是默认的。
但是，如果您有一个非常精确的用例，并且您确切地知道需要什么，并且只知道需要什么，那么您可以利用散列索引。
实际上，根据以下link，MySQL似乎使用散列表或b树这两种索引。
使用b-tree和哈希表之间的区别在于前者允许你在使用=，>，> =，<，<=或BETWEEN运算符的表达式中使用列比较，而后者仅用于使用=或<=>运算符的等式比较。
哈希表的时间复杂度仅对于足够大小的哈希表是恒定的（需要有足够的桶来保存数据）。事先不知道数据库表的大小，因此必须立即对表进行重新分析，以便从哈希表中获得最佳性能。重组也很昂贵。
我认为Hashmaps也不会扩展，并且当需要重新整理整个地图时可能会很昂贵。