使用字符串作为 PK 与使用具有唯一名称约束的 GUID 或 int Id答案

【问题标题】：Using string as PK vs using GUID or int Id with Unique Constraint for Names使用字符串作为 PK 与使用具有唯一名称约束的 GUID 或 int Id
【发布时间】：2012-06-11 13:37:06
【问题描述】：

您好，我想知道对于您具有必须唯一记录的表的最佳做法是什么。我已经看到了两种方法：使用主键或向列添加唯一约束。

如果您使用主键，那么使用 varchar(*) 之类的主键（例如“UserName”）是一种不好的做法吗？这对性能的影响是否足以导致问题？是否最好使用对用户名具有唯一约束的整数 id？

我看到了一些其他因素可能会影响将列选择为 PK 与 Unique。这些我说得对吗？

PK - 列应该是永远不需要更改的列

独一无二 - 列可以稍后更改

【问题讨论】：

这个问题可以通过快速的互联网搜索和/或一些研究来回答。
如果我在搜索中发现了我认为回答了我的问题的信息，那么我就不会在这里发帖了。只是说'
部分回答：mitch-wheat.blogspot.com.au/2011/08/…

标签： sql database-design relational-database

【解决方案1】：

在 UserName 上设置主键并不是最好的主意，但它的性能并没有您想象的那么差。

最好的办法是使用 ID (INT) 作为 PRIMARY KEY，使用 UserName 作为 UNIQUE。

【讨论】：

经过相当多的搜索后，我发现了这个论坛帖子，实际上显示了使用 varchar 时的性能下降。有意义，因为数字需要更少的数据来表示它们，从而使它们自动更有效。 dbasupport.com/forums/archive/index.php/t-34689.html
@user109309 自然键倾向于更好地聚集数据，尤其是在聚集（也称为索引组织）表中用作聚集索引时。因此，哪个“更快”实际上取决于正在执行的查询类型。例如，我希望对 INT 进行简单的 equi-search 更快，但是如果您需要对 VARCHAR 进行范围扫描，那么单独的 INT PK 不会真正帮助您（实际上它可能会伤害您，尤其是在使用集群时表）。

【解决方案2】：

用户名会随着时间而变化，这就是为什么它们不适合进行 PK，尤其是因为您极有可能有与用户名相关联的子记录。例如，假设我的用户名包含我真实姓名的一些变体。如果我后来离婚并恢复了我的婚前姓氏，我最不想做的就是提醒我结婚的那个 SOB，所以我改变了我的用户名。你真的想改变我在过去十年中发布的 200 万个帖子吗？我不这么认为。

是的，字符串比较速度较慢，但这可能是也可能不是问题，具体取决于数据库将获得的总体操作量。少于 200 个用户的小型数据库，可能不是问题，拥有数百万用户的 Internet 站点，更可能是问题。

【讨论】：

【解决方案3】：

正如其他人已经讨论过的那样，这可能是一个好主意，也可能不是一个好主意。让我再补充一点……

我发现了一些其他因素可能会影响将列选择为 PK 与 Unique。

主要区别通常与clustering有关。大多数 DBMS（支持集群）自动使用 PK 作为集群索引。例如 MySQL/InnoDB always 集群数据并且你不能关闭它，而 MS SQL Server 默认集群（你必须使用特殊的语法来关闭它）。

如果您选择使用集群（或被您的 DBMS 强制使用），索引越少通常越好（例如，请参阅 this article 中的“集群的缺点”），即使会导致“更胖”的外键。

【讨论】：