Web PK，自动增量与 UUID 样式，哪个更好，为什么？答案

【问题标题】：PK for web, autoincrement vs UUID style, which is better and why?Web PK，自动增量与 UUID 样式，哪个更好，为什么？
【发布时间】：2010-03-04 09:46:40
【问题描述】：

自动增量和 UUID 样式的真正区别是什么？

我认为 auto inc 与 uuid 相比很容易破解

在多条记录的查询中，Uuid 比自增慢，但是有很大的不同吗？

【问题讨论】：

【解决方案1】：

从关系模型的角度来看，主键非常重要

PK越小越好。这就是为什么 numeric PK 是最好的。

如果您担心它很容易被“破解”，您可以添加一个额外的 UUID 作为自然键

这是我在几个项目中看到的，它就像一个魅力。

【讨论】：

是的，我认为这是我正在寻找的答案，因此，解决方案是在数据库上下文中使用自动 inc PK 并拥有外部上下文的 UUID 键。我有这个困境，因为如果我有一个类似 domain.com/tickets?id=1 的链接来显示某事的票，任何人都可以尝试更改 id 以访问所有内容，因为这是可预测的
是的。但是请注意，最终的解决方案是使用身份验证并禁止访问基于某些权限方案不允许您访问的票证。 UUID 也不是真正意义上的安全。但恕我直言，在现实世界中识别票证的 UUID 和数据库的数字 PK 无论如何都是有用的。

【解决方案2】：

增量 ID 本身并不“容易破解”，它只是提供在您使用大随机 ID 时被隐藏（但并非完全隐藏）的入口点。仍然需要糟糕的实施和可利用的软件才能存在真正的危险。正如您在地址栏中的 URL 中看到的那样，该站点使用增量 ID 没有任何问题。

除了安全考虑之外，当您不希望用户轻易猜测其他（尽管是公开的）内容的 URL 时，随机唯一 ID 有时会很有帮助。例如，在一个房地产网站上，您可能不想提供在 ID 中“上下”查看竞争对手的条目的可能性，即使他们可以通过搜索找到它们。有点阻碍可能是一件好事。

为什么不同时使用？用于加快索引和关系的数字自动增量键；用于外部访问的随机 UID。

【讨论】：

是的，我想我会这样做，同时使用两者，实际上我会像往常一样使用 auto-inc 但对于用户，我们将使用 base36 对 id 进行哈希处理，正如我之前所说的，我的问题是我们需要给用户一个链接才能访问他们的票，所以如果我使用 domain.com/tickets?id=1 是非常可预测的

【解决方案3】：

一些想法：

auto-inc：DB 确保唯一 ID，但您必须检索它，否则您将失去与刚刚插入的数据记录的“联系”。
UUID：必须在“外部”创建（不在数据库服务器中，可能在应用服务器中）。 ID 是已知的，并且存在插入记录的链接，但是（非常小，取决于 uuid 的 uuid）插入时存在冲突风险。

【讨论】：

【解决方案4】：

注意 PK 列的长度...UUID 和 GUID 非常长...字符串。 INT 甚至 BIGINT 自增列可以在更小的空间内确保唯一性。

请注意，自动增量列在表管理方面存在一些问题。如果您截断/删除创建表，那么自动增量将难以维护。另外，在 MySQL 中，一个表只允许有 1 个自增列。

如果您的数据允许，请使用从数据中派生的某种 HASH 用于索引和性能。

【讨论】：