……我们一开始是在本地运行数据库。每个分支机构或门店都有自己的数据库。15年后，持续联网成为可能。再15年后，所有企业都使用了光纤。现在所有的分支机构都使用一个巨大的共享在线数据库。数据被合并。如果使用UUID，这个任务将变得微不足道。如果使用BIGINT，那就不是了。在同一时间线中，数据开始从我们的数据库中逃逸出去。它会去到手机上，四处旅行，发生变化，获得新记录，然后回家。想象一下很多销售人员在没有信号的地方工作的情景。因此，你在单一数据库（集群）的上下文中是对的，这个数据库始终包含所有数据。但在数据超出数据库范围的上下文中，使用UUID可以解决很多问题。还有其他地方UUID也很出色。因此，就像大多数关于SQL的建议一样，我想加上“上下文很重要”。
源讨论UUID的用户体验原帖 206 条评论 · 导入时统计UUID不应该用作数据库主键，除非数据库管理系统推荐这样做，或者你有经过深入研究的特殊原因。Postgres和MySQL默认应该使用bigserial，即使是Citus也是如此。一些特殊的分片数据库系统如Spanner需要非顺序的主键，但即使Spanner也明确告诉你使用uuid4，因为k-排序的键会导致热点问题：https://cloud.google.com/spanner/docs/schema-design#uuid_pri...
完整原文把你的经验，加入这段讨论。
你怎么知道用UUID会更好呢？你做过负载测试吗？你的数据集有多大？
完整原文当数据超出数据库范围时，你需要一个UUID，但不需要作为你的主键。即使是一个典型的后端-前端应用，只有一个数据库，通常也会通过API发送UUID。 如果你在复制数据库，进行修改，然后合并回来，你只需要重置大整数主键。在某些情况下这可能不太方便（或者如果合并非常频繁而读取不频繁，可能性能较差），但这是一种特殊情况，不应该从一开始就假设。例如，我之前轻松地用大整数做过这样的合并，也曾在一些地方一开始使用UUID主键，但从未从中受益。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。