我应该使用整数主ID吗？

Question

例如，我总是为users表生成一个自动增量字段，但我还在其用户名上指定了一个UNIQUE索引。在某些情况下，我首先需要获取给定用户名的userId，然后执行所需的查询，或在所需的查询中使用JOIN。它是数据库的2次访问或JOIN与varchar索引。

我应该使用整数主ID吗？

对于小 VARCHAR索引，INT是否有真正的性能优势？

Answer 1

拥有代理主键有几个优点，包括：

当你在另一个表中有一个外键时，如果它是一个整数，它只占用几个字节的额外空间，并且可以快速连接。如果您使用用户名作为主键，则必须将其存储在两个表中 - 占用更多空间，并且在需要加入时需要更长时间进行比较。

如果用户希望更改用户名，那么如果您将其用作主键，则会遇到很大问题。虽然可以更新主键，但这样做是非常不明智的，并且可能会导致各种问题，因为此密钥可能已发送到各种其他系统，用于链接，保存在备份中，具有日志已存档，等等。您无法轻松更新所有这些地方。

Answer 2

这不仅仅是关于表现。由于其他地方有充分记录的原因，您永远不应该键入有意义的值。

顺便说一句，我经常将int的类型缩放到表的大小。当我知道一个表不会超过255行时，我使用tinyint键，对于smallint也是如此。

Answer 3

除了别人所说的，你还需要考虑表的聚类。

在SQL Server（例如，可能还有其他供应商）中，如果主键也用作表的聚簇索引（引用通用），则递增整数优于其他字段类型。这是因为输入的新行的主键总是大于前面的行，这意味着新行可以存储在表的末尾而不是中间（同样的情况可以使用其他字段类型为主键创建，但整数类型更适合自己。）

将它与guid主键进行比较 - 必须将新行插入到表的中间，因为guid是非顺序的，因此插入效率非常低。

Answer 4

首先，很明显，在小桌子上，它在性能方面没有任何区别。只有非常大的桌子（多大程度取决于众多因素），它能否因为少数原因而有所作为：

1. 使用32位只会消耗4个字节的空间。据推测，您的用户名将超过四个非Unicode字符，因此占用的空间超过4个字节。使用的空间越多，页面上的少量数据就越合适，索引越多，产生的IO就越多。

2. 除非您强制每个人都拥有相同大小的用户名，否则您的字符列将需要使用varchar over char。这也将产生微小的性能和存储影响。

3. 除非您使用二进制排序归类，否则在比较两个字符串时，系统必须进行相对复杂的匹配。这两列是否使用相同的碰撞？对于每个角色，它们是否都是相同的？在匹配方面有哪些套管和重音规则？等等。虽然这可以很快完成，但是在一个非常大的表中，与整数匹配相比，它可以产生更大的影响。

我不确定为什么你不得不两次去数据库或加入varchar列。为什么你不能在数据库中进行一次访问（创建返回新的PK），你在整数PK上加入到用户表？