SQL 数据库中主键、自增和 UUID 的最佳实践

Question

我们正在为用户实体设计一个表。唯一重要的要求是用户实体（例如他们的个人资料）应该有一个永久的 URL。网上有很多关于 int/long vs UUID 的内容。但我仍然不清楚。

1. 考虑到配置文件包含私人信息这一事实，在 URL 中嵌入可预测的 ID 并不是一个好主意。我对吗？
2. 为了满足第一个，我可以将主键作为 UUID 并将其嵌入到 URL 中。但是有两个问题。我是否应该担心以 UUID 作为主键的性能损失？索引，插入，选择，加入？

话虽如此，以下哪一项更好（相对于上述）？

 CREATE TABLE users(
  pk UUID NOT NULL,
  .....
  PRIMARY KEY(pk)
);

或者

CREATE TABLE users(
  pk INT NOT NULL AUTO_INCREMENT,
  id UUID NOT NULL,
  .....
  PRIMARY KEY(pk),
  UNIQUE(id)
);

原文由 Rad 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

这实际上是一个选择问题，从我的角度来看，这个问题可以提出基于意见的答案。我总是做的，即使它是多余的，我在自动增量列上创建主键（我称之为技术键）以使其在数据库中保持一致，允许“主键”更改以防在设计阶段出现问题和还允许在任何其他表中的外键约束指向键的情况下消耗更少的空间，并且我使候选键唯一且不为空。

技术密钥是您通常不会向最终用户展示的东西，除非您决定这样做。对于您仅出于任何目的（例如修改日期、创建日期、版本、更改记录的用户等）而保留在数据库级别的其他技术列，这可能是相同的。

在这种情况下，我会选择您的第二个选项，但稍作修改：

 CREATE TABLE users(
  pk INT NOT NULL AUTO_INCREMENT,
  id UUID NOT NULL,
  .....
  PRIMARY KEY(pk),
  UNIQUE(id)
);

原文由 Kamil Gosciminski 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

使用 UUID 作为 pk ：第一个问题是，UUID 占用 9x 存储而不是 int 。第二个问题是，如果您需要更频繁地按 pk 排序，甚至不要考虑 UUID。 UUID 为 pk 不会影响 where 条件或除 sort 之外的其他条件的时间复杂度。

使用 int 作为 pk ：很容易猜到。蛮力攻击者会喜欢这个。这是唯一但最大的问题。

使用 int 作为 pk 但是，也要保留 UUID ：如果 UUID 不是 pk 那么通过 UUID 搜索的时间复杂度将会增加。即使所有关系都将由 int 维护，但是，当您按 UUID 搜索时，这需要时间。由于关系在 int 上，因此 9x 存储问题在这里得到解决。

原文由 Amimul Ehshan 发布，翻译遵循 CC BY-SA 4.0 许可协议