UUID支持分布式但占空间，序列高效但限单库；根据系统架构与安全需求选择主键方案。
在 PostgreSQL 中设计表结构时，主键的选择是一个关键决策。常见的方案有使用 UUID 和 序列（SERIAL 或 IDENTITY）。两者各有优劣，适用场景也不同。下面从多个维度对比分析，帮助你在实际项目中做出合理选择。
1. 唯一性与分布式支持
UUID 是全局唯一标识符，通常由 128 位字符串表示（如 a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11）。它在生成时就能保证跨节点、跨数据库的唯一性，非常适合分布式系统、微服务架构或需要合并多个数据源的场景。
序列（如 SERIAL、BIGSERIAL、IDENTITY 列） 依赖数据库内部的自增机制，只能保证单库内的唯一性。如果存在多个数据库实例或需要分库分表，自增 ID 很容易发生冲突，扩展性受限。
- 需要多节点写入或未来可能拆分数据库？优先考虑 UUID
- 单体应用、中心化数据库？序列完全够用且更高效
2. 性能与存储开销
UUID 占用 16 字节，而整型序列通常使用 4 字节（SERIAL）或 8 字节（BIGSERIAL）。更大的主键意味着：
- 每条记录的主键字段更大，增加表空间占用
- 索引体积膨胀，影响缓存效率和 I/O 性能
- B-tree 索引插入时因随机性导致页分裂更频繁
相比之下，序列生成的整数连续紧凑，索引结构更紧凑，范围查询和排序性能更优。尤其在大表上，这种差异会逐渐显现。
3. 可读性与调试便利性
整型 ID 如 1, 2, 3... 直观易记，便于开发调试、日志追踪和手动构造 API 请求。而 UUID 长度长、无规律，肉眼难以分辨，不利于人工操作。
不过可通过生成可读时间戳前缀的 UUID 版本（如 UUIDv7）缓解该问题，但 PostgreSQL 当前原生不支持 UUIDv7（需插件或自定义函数）。
4. 安全性与信息泄露
自增 ID 暴露业务增长趋势，攻击者可通过枚举 ID 猜测数据总量或访问未授权资源（如 /api/users/1001）。使用 UUID 能有效防止此类“ID 推测”攻击，提升接口安全性。
如果你的系统对外暴露资源 ID，建议使用 UUID 或其他不可预测的标识符。
5. 实际使用建议
根据应用场景灵活选择：
- 内部管理系统、后台任务表、日志表等：推荐使用 SERIAL 或 GENERATED AS IDENTITY，简单高效
- 用户表、订单表、API 资源表等对外暴露的实体：推荐使用 UUID，增强安全性和扩展能力
- 混合架构下可采用“双主键”策略：用 UUID 作逻辑主键（primary key），序列作物理自增 ID（用于内部排序或分页）
- 若选 UUID，建议使用 gen_random_uuid()（需启用 pgcrypto 扩展）生成 v4 UUID
基本上就这些。没有绝对最优，只有更适合当前架构和业务需求的选择。理解各自的边界，才能在扩展性、性能与安全性之间取得平衡。
