使用 UUID 作为小型 SQL 表的主键答案

【问题标题】：Using a UUID as a primary key for small SQL tables使用 UUID 作为小型 SQL 表的主键
【发布时间】：2017-04-26 20:35:19
【问题描述】：

我了解到，由于大型数据集的大小和性能问题，通常不建议将 UUID 作为主键。

但是，在一些顶级组织表上使用它会不会有害？例如。 Organization 或 Branch，只有少数条目？

【问题讨论】：

您是指 GUID 吗？简而言之，没有。但是您可能需要在事务表中反映这一点。此外，您应该在数据库中保持一致。 PK 是身份或 GUID，而不是混合。如果您有充分的理由使用 GUID - 即记录必须是普遍唯一的，那么请务必使用它。但是，如果您这样做只是为了避免对数据进行正确建模，那么这是一种糟糕的设计实践。
我不同意这个问题的前提。磁盘空间很便宜，作为主键，UUID 应该被很好地索引和高性能。
@Nick.McDermaid UUID 和 GUID 是一回事。 en.wikipedia.org/wiki/Universally_unique_identifier
糟糕，我错过了 Postgres，我对此知之甚少。
我们没有发现使用 guid 的任何问题。请参阅此算法codeproject.com/Articles/388157/…。我用大约 400 万行进行了测试；似乎还可以。对于小型数据集，如果您注意到差异，我会感到惊讶。

【解决方案1】：

我建议您使用 serial 而不是 UUID。为什么整数比 UUID 更可取？

在许多数据库中，表是使用主键进行物理排序的。在这样的数据库中，UUID 上的新插入几乎总是会“在”记录之间进行，这很昂贵。但是，Postgres 不支持聚集索引，因此底层数据没有排序。

整数有缺点：

除了空间使用之外，我认为在静态表上使用 UUID 并没有太大的危害。我非常喜欢整数，只有在整数难以计算的情况下才使用 UUID。

【讨论】：