我应该使用UUID作为PK +索引（user_id，UUID），还是单个复合（user_id，UUID）PK？

Question

一个相对菜鸟构建 Postgres SQL 数据库来按用户跟踪数据，其中每一行都保证分配有

uuid

和

user_id

，并且大多数查询是通过

user_id

和可选的

uuid

。

我想知道以下之间是否存在“明显更好的方法”：

1. 单个

   uuid

   PK，附有

   user_id

   +

   uuid

   索引
2. 复合

   user_id

   +

   uuid

   PK

感觉两者都能完成工作，但不确定

uuid

PK 的简单性和通过用户/uuid 进行检索的专用索引的效率之间是否存在明显的赢家，或者同时获得两者复合 PK（如果这很重要的话，这些不是会被用户“物理地定位”得更近吗？也许有一些额外的插入复杂性，尽管索引也会携带它？）

Answer 1

如果这就是数据库要做的全部事情：

...大多数查询都是通过

user_id

和可选的

uuid

。

那么选项 2 应该是最好的选择：

复合user_id+uuid PK

（

uuid

的唯一性不是通过这种方式强制执行的！）
领先

user_id

.

但我有点怀疑这就是完整的图景。 DB 优化始终取决于整体情况。

通常，您还对

uuid

有疑问。 （或者仅指向该列的 FK 约束？或者与表的 PK 一起使用的其他设计元素？）那么选项 1 显然更好。参见：

• 复合索引也适合第一个字段的查询吗？

此外，仅在确实需要时才使用 UUID。否则，

bigint

更有效率。参见：

• PostgreSQL 使用 UUID 与 Text 作为主键

为了增加每个用户的数据局部性，时不时地在索引上使用

CLUSTER

应该有助于

user_id

的索引。参见：

• 优化Postgres对时间戳范围的查询