Mysql 在哈希索引上插入主键表的时间复杂度

我刚刚发现内存表中哈希索引列上的主键本身就是哈希索引，如下所示：

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)

---

我想知道：既然主键必须检查其列中新条目的唯一性，这是否意味着插入

test\u内存

是在

O（n）

时间，而不是

O（log n）

对于具有BTREE主键的表，时间？

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

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

因此，散列可以比b-树更快。也就是说，当b树比可用内存大时，b树的伸缩性更好，更易于管理