在数据库表设计阶段，主键类型的选择往往决定了后续几年的维护成本。自增整数主键简单高效，但在多库多表合并、离线数据同步、暴露业务ID风险等场景下就显得力不从心，UUID因为全局唯一、无需中心节点协调的特性成了热门替代方案。PostgreSQL对UUID提供了原生支持，有专门的uuid数据类型（16字节存储），生成方式也有好几种，不同方式在性能、有序性、依赖程度上差异不小，下面逐一展开。
一、PostgreSQL中生成UUID的三种主要方式
第一种是使用uuid-ossp扩展。这是PostgreSQL历史上最经典的方案，安装启用后可以调用uuid_generate_v1()（基于时间戳和MAC地址）、uuid_generate_v4()（纯随机）等一组函数。启用方式很简单：
-- 在目标数据库中执行一次即可 CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; -- 查看可用函数 SELECT uuid_generate_v1(); -- 带时间戳的版本，有一定顺序性 SELECT uuid_generate_v4(); -- 随机版本，最常用 SELECT uuid_nil(); -- 全零UUID，某些场景用作占位符
uuid-ossp的缺点是它依赖操作系统的OSSP UUID库编译，部分云数据库或精简安装环境可能没有编译这个扩展，导致部署时才发现不可用，这是实际项目中常见的坑。
第二种是使用pgcrypto扩展。它提供的gen_random_uuid()同样生成v4随机UUID，好处是pgcrypto在绝大多数发行版里都是默认可用的，兼容性比uuid-ossp好很多：
CREATE EXTENSION IF NOT EXISTS pgcrypto; SELECT gen_random_uuid(); -- 直接返回v4随机UUID
第三种也是目前最推荐的方式：PostgreSQL 13开始，gen_random_uuid()被内化为内置函数，不需要任何扩展就能直接使用。如果你的数据库版本在13及以上，直接调用即可，这也是官方文档当前推荐的标准做法。此外，PostgreSQL 18进一步引入了uuidv7()函数，可以原生生成时间有序的UUID v7，对于关注索引写放大问题的场景是重大利好。
二、UUID主键的默认值写法与建表示例
确定了生成函数后，建表时把它设为默认值即可。常见的写法有函数调用和DEFAULT表达式两种形式，效果一致：
-- PostgreSQL 13+ 推荐写法
CREATE TABLE orders (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
order_no varchar(32) NOT NULL,
amount numeric(12,2) NOT NULL,
created_at timestamptz NOT NULL DEFAULT now()
);
-- 老版本使用 uuid-ossp 的写法
CREATE TABLE orders_legacy (
id uuid PRIMARY KEY DEFAULT uuid_generate_v4(),
order_no varchar(32) NOT NULL
);
-- 已有表补充默认值
ALTER TABLE orders
ALTER COLUMN id SET DEFAULT gen_random_uuid();需要注意一点：如果客户端在INSERT时显式传入了id值，默认值不会生效。建议在应用层就做好约定，要么完全交给数据库生成，要么完全由应用生成，避免混用导致排查问题困难。另外插入后如果需要拿到生成的id，可以使用RETURNING子句，这是PostgreSQL的招牌特性：
INSERT INTO orders (order_no, amount)
VALUES ('SO20250601001', 199.00)
RETURNING id, created_at;四、随机UUID对索引性能的影响与有序UUID方案
UUID v4是完全随机的，这意味着新插入行的主键值会均匀落在B-tree索引的任意位置，而不是像自增ID那样只在最右侧追加。这个特性带来两个问题：一是索引页频繁分裂，页利用率下降，索引体积膨胀；二是写入时缓存命中率低，随机位置访问会导致更多磁盘IO，在数据量上千万、写入量大的表上表现尤其明显。
缓解这个问题有几条思路。第一条是使用UUID v1或v7这类时间有序的版本，新数据始终追加到索引右端，写入模式接近自增主键。可以用uuid-ossp的uuid_generate_v1()，或者干脆由应用层生成v7，比如Java生态里的常用UUID生成库基本都支持v7。第二条思路是牺牲一点随机性，把随机部分缩减为较短的前缀加上时间后缀，也就是所谓有序UUID的变种方案，不过这类自定义方案失去了标准性，跨系统对接时要多加小心。
实测数据可以作为参考：在千万级数据量的表上持续批量插入，随机UUID主键的索引大小通常比有序方案大百分之二十到四十，批量写入吞吐量也可能有明显差距。具体差异和硬件、行宽、批量大小都有关，建议在自己的真实数据模型上做压测再下结论，不要直接照搬别人的结论。
三、存储与应用层的取舍建议
关于存储，uuid类型固定16字节，比存储32位十六进制字符串的varchar(32)节省一半空间，且数据库会做格式校验，请务必使用原生类型而不是字符串。唯一索引、主键约束在uuid类型上的行为与其他类型一致，联表查询性能没有额外开销，主要瓶颈还是前面提到的随机写入问题。
在应用层生成还是在数据库层生成，也是团队经常讨论的话题。应用层生成的好处是插入前就拿到ID，方便构造关联对象、写日志做链路追踪；数据库层生成的好处是集中管控，任何客户端写入都有合法主键。如果是微服务架构、消息队列驱动的写入链路，推荐应用层生成；如果是多种工具直接写库的存量系统，数据库默认值更稳妥。两种方式在PostgreSQL里可以并存，默认值只作为兜底。
最后总结一下选型结论：PostgreSQL 13以上直接用内置的gen_random_uuid()，无需扩展；关注高并发写入性能就考虑v7有序UUID，PostgreSQL 18可直接用uuidv7()，旧版本由应用层生成；uuid-ossp仅在维护老系统时才需要接触。把版本、性能、运维便利性三个因素摆清楚，UUID主键的方案选择其实并不难。
PostgreSQLUUID主键uuid-ossp修改时间：2026-09-14 03:10:40