任何数据库都使用VARCHAR作为ID发出问题

Question

我正在构建一个数据库，并希望将VARCHAR用作某些表的ID /主键，因此它更加用户友好。我知道历史上存在系统限制/减速，所以使用尽可能小的数据类型是很好的做法。

使用当前的系统硬件，这有变化吗？我的意思是，我们是否仍然应该使用小数据类型，或者这是过去的事情吗？

谢谢，

Answer 1

这不是世界末日。但由于以下原因，不建议使用VARCHAR()主键：

• 它们通常比整数占用更多空间。这在主表中几乎没有区别，但是外键使用的空间使用量是相乘的。
• 它们（通常）是可变长度的。这会给索引带来轻微的开销。不多，但为什么要这么麻烦？
• 他们（通常）没有订购。该表按主键排序，因此增加了页面拆分和碎片的可能性。
• 他们可能会改变。我只是发现级联外键关系是数据模型中的一个坏标志。

我建议使用自动递增的主键，varchar()列上有唯一索引，使用主键的所有外部引用。

Answer 2

考虑@ GordonLinoff的补充答案。

虽然您所陈述的字符串索引的说明是合理的，但您应该注意：

• 索引VARCHAR(X)等同于索引CHAR(X)，因为索引中的条目是常量。
• 在utf8 / utf8mb4排序规则中索引字符串类型意味着长度分别为3X或4X。

因此，如果您要索引utf8mb4 VARCHAR(255)列，则每个条目将需要大约1kB的索引空间/内存。 [以key length constraints为准，可能多于或少于此。]

其中一个并不比另一个好，因为你需要做出任何一种权衡取舍。代理键可以使索引大小保持较小，但需要额外的应用程序逻辑。自然键使用起来更自然，但通常需要更多的索引空间。