我正忙于新项目的数据库设计，我不确定是使用UUID还是普通表独特的自动增量ID。
到目前为止，我构建的网站都运行在一台服务器上，而且非常繁忙的流量从未像现在这样严重。但是，这个Web应用程序最终将在多个服务器上同时运行，提供API，并且需要每秒处理数千个请求，并且我想确保我现在选择的设计不会在以后削弱任何这些可能性。 / p>
我当然怀疑，他们应该通过我的问题表达方式清楚，但我想听听那些有经验的人，如果我有或没有经验，我会遇到什么麻烦UUID，以及我应该根据我做出的决定。
所以，简而言之：在决定是否对所有数据库模型使用UUID时应该考虑哪些因素，以便任何一个对象都可以由一个字符串唯一地标识，以及何时是否适合将其用作主键，而不是逐表自动增量？
注意：我看过this question (When are you truly forced to use UUID as part of the design?)并阅读了所有答案，但他们主要回答“UUID很少发生冲突”，而不是“何时使用它们” ”
答案 0 :(得分：2)
我在决定UUID与自动增量ID时使用的一个考虑因素是它们是否会被用户看到，如果是，我是否希望用户知道我有多少该表。例如，如果我不想公开我的网站注册用户的数量，我就不会分配自动增量用户ID。
为了解决您提出的另一个特定问题，仍然可以使用具有多个服务器的自动递增ID（尽管不使用内置MySQL）。您只需要在不同的偏移量处启动所有ID，并相应地增加。也就是说，如果你有3台服务器，你可以启动服务器A为1，服务器B为2，服务器C为3，然后每次增加10而不是1.这样，你可以保证没有冲突。
最后，我考虑的最后一件事是性能对我的应用程序有多重要。整数比基于字符串的UUID更容易编入索引，因此索引更小，搜索速度更快等等。
答案 1 :(得分：1)
尤其是对于网络而言，UUID或GUID非常有用。如果您使用自动增量值来存储UserId，则任何人都可以查看您的网页来源并查看其使用的简单性。然后，他们可以尝试任何整数值来获取他们不应该看到的数据。
GUID不是以任何顺序格式创建的，因此如果您一个接一个地创建它们，那么序列就不容易被猜到。
我认为没有必要将GUID用于简单的查找类型数据，例如ColorId 1 = Blue，2 = Red，3 = Green。
GUID对会话和状态管理也非常有用。
这是我的0.02美元