什么时候适合在 Web 项目中使用 UUID？答案

【问题标题】：When is it appropriate to use UUIDs for a web project?什么时候适合在 Web 项目中使用 UUID？
【发布时间】：2012-03-11 17:40:18
【问题描述】：

我正忙于一个新项目的数据库设计，我不确定是使用 UUID 还是使用普通的 table-unique auto-increment id。

到目前为止，我建立的网站都在一台服务器上运行，非常大的流量从来都不是什么大问题。然而，这个 Web 应用程序最终会在多个服务器上同时运行，提供一个 API，并且需要每秒处理数千个请求，我想确保我现在选择的设计不会在以后削弱任何这些可能性。

当然，我有我的怀疑，通过我提出问题的方式应该很清楚，但我想听听那些有更多经验的人，如果我有或没有，我以后会遇到什么麻烦UUID，以及我真正应该基于什么做出决定。

所以，简而言之：在决定是否对所有数据库模型使用 UUID 时，我应该考虑哪些因素，以便任何一个对象都可以由一个字符串唯一标识，以及何时将其用作主键而不是逐表自动增量是否合适？

注意：我看过this question (When are you truly forced to use UUID as part of the design?)，并阅读了所有答案，但他们大多回答“UUID 冲突的频率如何”，而不是“何时适合使用它们”。

【问题讨论】：

标签： database database-design architecture uuid

【解决方案1】：

在决定 UUID 还是自动增量 ID 时，我使用的一个考虑因素是它们是否对用户可见，如果是，我是否希望用户知道我有多少张表。例如，如果我不想公开我网站的注册用户数量，我就不会分配自动递增的用户 ID。

为了解决您提出的另一个具体问题，仍然可以对多台服务器使用自动递增的 id（尽管不能使用内置的 MySQL）。您只需要以不同的偏移量开始所有 id，并相应地递增。也就是说，如果您有 3 台服务器，您可以在 1 启动服务器 A，在 2 启动服务器 B，在 3 启动服务器 C，然后每次将 id 增加 10 而不是 1。这样，您可以保证没有冲突。

最后，我考虑的最后一件事是性能对我的应用程序的重要性。与基于字符串的 UUID 相比，整数更容易编入索引，因此索引更小、搜索速度更快等。

【讨论】：

【解决方案2】：

UUID 或 GUID 可能非常有用，尤其是对于 Web。如果您使用自动增量值来存储 UserId，任何人都可以查看您网页的源代码并了解其使用的简单性。然后他们可以尝试任何整数值来获取他们不应该看到的数据。

GUID 不是以任何顺序格式创建的，因此如果您一个接一个地创建它们，则不容易猜到顺序。

我认为没有必要将 GUID 用于简单的查找类型数据，例如 ColorId 1=Blue、2=Red、3=Green。

GUID 对于会话和状态管理也非常有用。

这是我的 0.02 美元

【讨论】：