PostgreSQL UUID 类型性能答案

【问题标题】：PostgreSQL UUID type performancePostgreSQL UUID 类型性能
【发布时间】：2015-04-26 16:10:38
【问题描述】：

我并不是要重新开始 UUID 与串行整数密钥的辩论。我知道任何一方都有有效的观点。我在几个表中使用 UUID 作为主键。

列类型："uuidKey" text NOT NULL
索引：CREATE UNIQUE INDEX grand_pkey ON grand USING btree ("uuidKey")
主键约束：ADD CONSTRAINT grand_pkey PRIMARY KEY ("uuidKey");

这是我的第一个问题；使用 PostgreSQL 9.4 将列类型设置为 UUID 是否有任何性能优势？

文档http://www.postgresql.org/docs/9.4/static/datatype-uuid.html 描述了UUID，但是除了类型安全之外，使用这种类型而不是text 类型还有什么好处吗？在字符类型文档中，它表明 char(n) 在 PostgreSQL 中不会比 text 有任何优势。

提示：这三种类型之间没有性能差异，除了从使用空白填充类型时增加的存储空间，以及几个额外的 CPU 周期来检查存储到长度受限的列。虽然字符（n）有性能在其他一些数据库系统中的优势，没有这样的优势在 PostgreSQL 中；事实上 character(n) 通常是最慢的三是因为其额外的存储成本。在大多数情况下，文本或应改用字符变化。

我不担心磁盘空间，我只是想知道是否值得花时间对 UUID 和文本列类型进行基准测试？

第二个问题，哈希与 b-tree 索引。对 UUID 键进行排序没有意义，那么 b-tree 是否比散列索引有任何其他优势？

【问题讨论】：

如果除了主键之外还创建唯一索引，则没有必要。当您设置主键时，会在该键上创建唯一索引。
我可能以错误的顺序显示它。索引是由主键约束自动创建的。
似乎，根据文档（在此评论时 9.4 是最新的稳定版本），不鼓励使用哈希索引：postgresql.org/docs/9.4/static/indexes-types.html
也许我对这篇文章有误解，但是当 Postgres 具有本机 UUID 列类型时，为什么要使用 TEXT 呢？ TEXT 有什么好处吗？
在 9.0 中添加了 UUID 列类型。该数据库最早创建于 8 年

标签： postgresql indexing hash uuid

【解决方案1】：

我们有一个包含大约 30k 行的表（出于特定的不相关架构原因），该表将 UUID 存储在文本字段中并进行了索引。我注意到查询性能比我预期的要慢。我创建了一个新的 UUID 列，复制到文本 uuid 主键中并在下面进行比较。 2.652 毫秒与 0.029 毫秒。差别很大！

 -- With text index
    QUERY PLAN
    Index Scan using tmptable_pkey on tmptable (cost=0.41..1024.34 rows=1 width=1797) (actual time=0.183..2.632 rows=1 loops=1)
      Index Cond: (primarykey = '755ad490-9a34-4c9f-8027-45fa37632b04'::text)
    Planning time: 0.121 ms
    Execution time: 2.652 ms

    -- With a uuid index 
    QUERY PLAN
    Index Scan using idx_tmptable on tmptable (cost=0.29..2.51 rows=1 width=1797) (actual time=0.012..0.013 rows=1 loops=1)
      Index Cond: (uuidkey = '755ad490-9a34-4c9f-8027-45fa37632b04'::uuid)
    Planning time: 0.109 ms
    Execution time: 0.029 ms

【讨论】：

【解决方案2】：

UUID 是一个 16 字节的值。与text 相同的是一个 32 字节的值。存储大小为：

select
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::text) as text_size,
    pg_column_size('a0eebc999c0b4ef8bb6d6bb9bd380a11'::uuid) as uuid_size;
 text_size | uuid_size 
-----------+-----------
        36 |        16

更小的表导致更快的操作。

【讨论】：

但是当涉及到 uuid 比较时它是如何反应的。使用 uuid 比 int 有什么好处吗
MAX(uuid_column) 不受支持，所以这是一个真正的区别。
@AlllainLalonde 你为什么想要那个？
关于 max(uuid) 的讨论可以在这里找到：dba.stackexchange.com/questions/275251/… – 有一些用例，可以很容易地添加为聚合函数