database - 什么时候适合将 UUID 用于 Web 项目？

Question

最近忙于新项目的数据库设计，不知道是用UUID还是普通的table-unique自增id。

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

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

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

注意:我见过this question (When are you truly forced to use UUID as part of the design?) , 并阅读所有答案，但他们大多回答“UUID 发生冲突的几率有多大”，而不是“什么时候使用它们合适”。

Answer 1

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

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

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