嘿，这个问题问到点子上了！我来给你详细拆解下PostgreSQL里存储UUID的几种方案，帮你选最适合的：

1. 优先选原生uuid类型（强推！） #

PostgreSQL其实自带了专门的uuid数据类型，它本质就是固定16字节的存储，和你在MySQL里用binary(16)的存储空间完全一样，而且比手动转字节靠谱太多：

• 不用自己做UUID和字节的转换，避免字节序错误或者转换bug
• 原生支持大量UUID相关函数，比如生成随机UUID：PostgreSQL 13+可以直接用gen_random_uuid()，更早版本装个uuid-ossp扩展就能用uuid_generate_v4()
• 可读性更好，查询时直接显示标准UUID字符串（比如a1b2c3d4-1234-5678-90ab-cdef01234567），不用手动解码bytea
• 索引优化更到位，B-tree索引对uuid类型有专门的优化，性能更稳定

举个创建表的例子：

CREATE TABLE posts (
    post_id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
    content text NOT NULL,
    created_at timestamptz DEFAULT now()
);

2. 非要用固定长度二进制？bytea也能实现，但没必要 #

你提到的bytea类型确实是可变长度，但当你存储16字节的UUID字节数据时，PostgreSQL会把它内联存储，实际占用空间和uuid类型完全一致。不过这种方式有几个明显的缺点：

• 你得自己处理UUID和字节的转换，比如把UUID字符串去掉-后转成十六进制字节：

  -- 生成UUID并转成bytea
  INSERT INTO posts (post_id) VALUES (decode(replace(gen_random_uuid()::text, '-', ''), 'hex'));
  -- 查询时转回UUID字符串
  SELECT encode(post_id, 'hex')::uuid FROM posts;
  

• 失去了原生uuid类型的所有函数支持，索引性能也没优势
• 可读性极差，直接查bytea列看到的是乱码或者十六进制串，排查问题很麻烦

总结 #

如果你追求存储空间优化，同时又想兼顾易用性和稳定性，原生uuid类型就是最优解——它和binary(16)一样只占16字节，还省去了手动转换的麻烦，自带的功能也能帮你少踩很多坑。

内容的提问来源于stack exchange，提问作者Monsta