InnoDB的哈希索引

Question

我看到了一个如下所示的数据库模式

CREATE TABLE foo (
    name_hash bigint,
    name varachar(500),
    a varchar(500),
    b varchar(500),
    ...
    PRIMARY KEY (name_hash),
    KEY ...
);

这似乎是试图通过使用8字节整数而不是100字节字符串来限制索引大小。当按名称查找值时，应用程序对其进行散列处理，然后在SQL查询中而不是在名称中使用该哈希。

这相当乏味，我不确定是否有必要。

MySQL InnoDB是否有类似的特性--通过其短得多的散列查找字符串，以便将索引放入内存？

还是它已经做了这样的事？

Answer 1

InnoDB没有任何工具可以做您所描述的事情。

InnoDB在索引中的每列限制为767字节。它有容纳VARCHAR(255) utf8或VARCHAR(191) utf8mb4的空间。此外，如果整个记录大于8KB，InnoDB希望将long VARCHARs放在不同的块中。这会很普遍吗？(当您可以合理地声明一个较小的限制时，不要盲目地使用VARCHAR(500)。)

计划A:压缩(在客户端) name并将其存储到VARBINARY(255)中。假设它是典型的文本，压缩大约是3:1。使用它而不是哈希。

方案B:将名称拆分为2或3列，以便遵守索引限制。(一个丑陋的解决方案！)

C计划:改变767的限制。(这是可能的，但我现在忘记了细节。)

要注意的是:任何像样的“散列”都是随机的。也就是说，每一行都会在表中的某个随机位置落地。一旦表超过innodb_buffer_pool_size，您将执行越来越多的I/O操作，从而降低速度。

SELECTs会是什么样子？这张桌子上还有其他索引吗？JOIN on name_hash好吗？所有这些都可能影响到设计模式的“最佳”方式。