我应该使用整数主ID吗？

Question

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

我应该使用整数主ID吗？

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

Answer 1

存在具有代理主键，其中的几个优点：

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

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

Answer 2

这不只是表现。由于在其他地方有详细记载的原因，您绝对不应该选择有意义的价值。

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

Answer 3

除了别人所说的之外，您还需要考虑表格的聚类。

在SQL Server（例如其他供应商）中，如果主键也用作表的聚簇索引（这是常见的引用），则增量整数将比其他字段类型有所好处。这是因为新行使用始终大于前一行的主键输入，这意味着新行可以存储在表的末尾而不是中间（这种情况下可以与其他一起创建主键的字段类型，但整数类型更适合自己）。

将此与guid主键进行比较 - 由于guid是非顺序的，所以必须将新行插入到表的中间，从而导致插入非常低效。

Answer 4

首先，很明显，在小桌子上，它对性能没有影响。只有在非常大的表（有多大取决于许多因素），它可以使的原因有几个差别：

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

2. 除非您强制每个用户拥有相同大小的用户名，否则您的字符列将要求使用varchar字符。这也将具有很小的性能和存储影响。

3. 除非您使用二进制排序归类，否则系统在比较两个字符串时必须进行相对复杂的匹配。两列是否使用相同的相互关系？对于每个角色，他们都是一样的吗？匹配方面的外壳和重音规则是什么？等等。虽然这可以快速完成，但是在一个非常大的表中，与在整数上进行匹配相比，可以做出更多的工作。

我不知道为什么你永远不得不做两次到数据库或加入一个varchar列。为什么你不能一次去数据库（创建返回你的新PK），你加入到整数PK的users表中？