Her*_*aaf 5 database architecture uuid database-design
我忙于新项目的数据库设计,我不确定是使用UUID还是普通的表独特的自动增量ID.
到目前为止,我构建的网站都运行在一台服务器上,而且非常繁忙的流量从未像现在这样严重.但是,这个Web应用程序最终将在多个服务器上同时运行,提供API,并且需要每秒处理数千个请求,我想确保我现在选择的设计不会在以后削弱任何这些可能性.
当然,我有我的怀疑,他们应该通过我的问题表达方式清楚,但我想听听那些有经验的人,如果我有或没有UUID,我会遇到什么麻烦,以及我应该根据我的决定做些什么.
因此,简而言之:在决定是否对所有数据库模型使用UUID时,我应该考虑哪些因素,以便任何一个对象都可以由一个字符串唯一地标识,何时将其用作主键是合适的而不是逐表自动增量？
注意:我已经看到了这个问题(你什么时候真的被迫使用UUID作为设计的一部分？),并阅读所有的答案,但他们主要回答"UUID很少碰撞",而不是"什么时候适当使用它们".
在决定 UUID 与自动增量 id 时，我考虑的一个因素是它们是否对用户可见，如果是，我是否希望用户知道我拥有该表的数量。例如，如果我不想公开我的网站的注册用户数量，我就不会分配自动增量用户 ID。
为了解决您提出的另一具体问题，仍然可以在多个服务器上使用自动递增 id（尽管不能使用内置 MySQL）。您只需要以不同的偏移量开始所有 id，并相应地递增。也就是说，如果您有 3 个服务器，您可以在 1 处启动服务器 A，在 2 处启动服务器 B，在 3 处启动服务器 C，然后每次将 id 增加 10 而不是 1。这样，您就可以保证不会发生冲突。
最后，我考虑的最后一件事是性能对我的应用程序有多重要。整数比基于字符串的 UUID 更容易索引，因此索引更小、搜索速度更快等。