Question

我刚刚发现MEMORY表中HASH索引列的PRIMARY KEY本身就是HASH索引，如下所示：

mysql> CREATE TABLE `test_memory` (
    -> `id` int(11) NOT NULL AUTO_INCREMENT,
    -> PRIMARY KEY (`id`),
    -> KEY `id` (`id`) USING HASH
    -> ) ENGINE=MEMORY DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.10 sec)

mysql> SHOW INDEXES FROM test_memory;
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table       | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| test_memory |          0 | PRIMARY  |            1 | id          | NULL      |           0 |     NULL | NULL   |      | HASH       |         |               |
| test_memory |          1 | id       |            1 | id          | NULL      |           0 |     NULL | NULL   |      | HASH       |         |               |
+-------------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
2 rows in set (0.00 sec)

我当时想知道：由于PRIMARY KEY必须检查新条目在其列中的唯一性，这是否意味着插入test_memory的时间是O(n)，而不是{{1}在具有BTREE PRIMARY KEY的表的情况下的时间？

Answer 1

哈希结构可以在O（1）时间内识别散列桶中的非冲突 - 理论上比b树更快。哈希不 O（n），除非“n”是单个键中的位数（通常是指记录数）。

冲突是一个问题，因为您必须测试哈希桶中的每个值。这取决于底层实现。有时，使用列表;有时树木;有时候是另一层次的哈希。在任何情况下，如果你合理地假设哈希表永远不会超过x次冲突，那么复杂度就是O（x）== O（1）。

出于这个原因，哈希可以比b树快。也就是说，当b-trees比可用内存更大时，b-tree可以更好地扩展并且更易于管理。

在HASH索引上使用PRIMARY KEY插入表的时间复杂度

1 个答案: