MySQL varchar 索引存储

Question

我有一个使用 Laravel 框架构建的应用程序。它的功能之一是能够在表之间创建多态关系。它通过存储相关表的 ID 和相关表模型的完全限定类名来实现这一点。可以想象，某些条目可能会很长，具体取决于模型的命名空间和类名。

在我的场景中，我有 4 张桌子。基表A 是多态的。表 B、C 和 D 不是。

非多态表模型的类名如下：

LongNamespace\SubNamespace\Something\B
LongNamespace\SubNamespace\Something\C
LongNamespace\SubNamespace\Something\D 

A 表中的结果如下所示：

id | relation_id | relation_type
--------------------------------
1  | 1           | LongNamespace\SubNamespace\Something\B
2  | 2           | LongNamespace\SubNamespace\Something\C
3  | 5           | LongNamespace\SubNamespace\Something\D
4  | 12          | LongNamespace\SubNamespace\Something\D
5  | 3           | LongNamespace\SubNamespace\Something\B
6  | 6           | LongNamespace\SubNamespace\Something\C

... etc (around 50,000 rows) ...

每条记录添加 38 个字节，其中大部分是重复数据，我的问题是，是否会在 relation_type 列上添加一个索引，将每个 relation_type 记录单独存储在内存中（我假设这是索引会发生的情况) 还是将它们像 ENUM 一样分组，所以总存储量将是 relation_type 中的 3 个唯一条目，然后通过某种哈希表在内部关联，从而节省 n*38 字节的空间。

Answer 1

索引包含所有索引列的所有文本，加上（在 InnoDB 的情况下）所有 PRIMARY KEY 列的所有文本。因此，38*n 字节被“浪费”了。

如果你声明 relation_type 是

ENUM(`LongNamespace\SubNamespace\Something\B`,
     `LongNamespace\SubNamespace\Something\C`,
     `LongNamespace\SubNamespace\Something\D`,
     ...)

那么它只需要 1 或 2 个字节，但其行为与那些 39 字节的字符串非常相似。

当你添加另一个表等时，当然存在维护问题。

另一方面，38*50K = ~2MB 是“小”，并不是什么大问题。

不，索引不会保存在 RAM 中。但是，它是逐块“缓存”在 RAM 中的。因此，如果索引（或表）真的很大，由于没有留在缓存（RAM）中的东西，将会有额外的 I/O。但它仍然会“工作”，尽管速度很慢。