我应该如何在Postgres中为UUID编制索引？

我是PostgreSQL的新手，而对于数据库则是新手。有没有确定的方法来索引Postgres中的UUID值？我在使用散列和使用Trie之间是分开的，除非已经有一些内置的东西可以自动使用。无论我使用什么，都将处理大量数据。

SP-GiST运算符系列“ text_ops”使用特里索引。因为UUID很长且非常不同，所以即使我只进行完全匹配搜索，这些听起来也很吸引人。

还有一个哈希选项。哈希为O（1），我当然不需要做任何比较，但是，由于UUID很长，因此恐怕从它们生成哈希值会浪费很多时间。

还是这过于依赖系统和使用细节？

在大多数情况下，我宁愿使用bigserial，但有人告诉我为此使用uuid。我们需要uuid，因为我们可能有多个使用不同数据库的服务器，因此不能保证我们将拥有唯一的bigint。我们可以为每个服务器使用不同的序列（和种子），但是它仍然不如UUID灵活。例如，如果不将ID及其引用转换到各处，就无法将数据库条目从一台服务器迁移到另一台服务器。

postgresql index uuid

— 须藤
source

我相信“联合数据库”是您所处情况的流行语。而且，是的，UUID是解决方案。这就是几十年前发明UUID的原因：无需分布式协调就可在分布式系统之间共享数据。

— 罗勒·布尔克

几个月后：的确，Basil Bourque提出的“联合数据库”就是我们要的目标。我们不仅有多个服务器，而且还有一些客户端（可以将其视为联邦DB的更多部分）在离线时创建ID。这就是为什么我们使用UUID。

— sudo 2015年

Answers:

使用PostgreSQL的内置uuid数据类型，并在其上创建常规b树索引。

无需执行任何特殊操作。这将导致最佳索引，并且还将uuid以当前实用的紧凑格式存储字段。

（PostgreSQL 10之前的版本中的哈希索引不是崩溃安全的，并且实际上是一个历史遗迹，无论如何，它的性能往往不比b树好。请避免使用它们。在PostgreSQL 10上，它们已成为崩溃安全的，并且具有一些性能方面的改进，因此您不妨考虑一下。）

如果由于某种原因您不能使用该uuid类型，则通常会在文本表示形式或byteauuid表示形式上创建b树。

— 克雷格·林格
source

尽管有关hash索引与索引的声明b-tree是一种普遍的看法，但我认为引用此类声明的来源会有所帮助。

— Volte

从PostgreSQL 10开始，hash索引现在是崩溃安全的。也就是说，hash索引只能与一起使用=，因此，如果需要任何其他运算符，b-tree还是更好的选择。

— rintaun

几年后，以我的经验，即使在Postgres 10中，hash也没有比快很多b-tree。但是，由于散列索引占用的磁盘空间比b树少得多，因此在大索引成为a索引的设置中可能会更快问题，我觉得情况并非如此。好吧，现在我可以注意在v10中可以安全地安全使用它们了。

— sudo

有散列索引一些好写UPS PERF的V10和V11改进：rhaas.blogspot.com/2017/09/... - amitkapila16.blogspot.com/2017/03/...

— 格伦莫顿

PostgreSQL中缺少哈希索引。PostgreSQL知道它需要哈希索引，并且哈希索引的代码既旧又发霉，但他们不会删除它，因为它们正在等待有人来检查哈希索引。看到这个线程：

http://www.postgresql.org/message-id/4407.1115698257@sss.pgh.pa.us

— 德雷克
source

是的，当我尝试使用哈希索引时会收到警告。“强烈劝阻”之类的。

— sudo

在某些情况下，哈希索引在PostgreSQL中可以很好地工作，但是最近我发现，当我尝试对内置UUID数据类型主键和外键进行哈希索引优化时，它们导致查询不返回任何结果。哈希索引确实有很多好处，只要它们适用于所有数据类型，并且PostgreSQL开发人员知道这一点，他们就懒得自己修复它，并且将代码放置在原处，就好像他们为最终祈祷救主。

— derekm '16

有人救了散列索引，我猜是因为它们在数据分区中起关键作用，这PG10一直专注于：wiki.postgresql.org/wiki/...但是他们仍然不给你的一切，我看到理论上在大学数据库课程中很有用；）

— sudo