联合主键适用于多对多关联表、具有自然复合唯一性的业务实体、时间序列或分区表场景，能提升语义清晰度与查询效率，但应控制列数、注意顺序、避免可变字段，并考虑查询模式与外键匹配，必要时可用唯一约束加代理主键替代。
在设计 PostgreSQL 数据库时，选择合适的主键策略对数据完整性、查询性能和表结构合理性至关重要。联合主键（也称复合主键）由两个或更多列共同组成主键，用于唯一标识表中的每一行。它并不总是最佳选择，但在特定场景下非常合适。
何时使用联合主键更合适？
联合主键适用于那些自然业务逻辑中就依赖多个字段才能唯一确定一条记录的场景。以下情况建议考虑使用：
- 关联表（多对多关系中间表）：例如用户与角色之间的权限分配表 user_roles(user_id, role_id)，单个字段无法唯一标识，但组合可以。
- 具有自然复合唯一性的业务实体：如订单明细表中的 (order_id, product_id)，同一订单中每个商品只出现一次。
- 时间序列或分区表中的分片键组合：比如按租户和日期划分的数据表，(tenant_id, log_date) 可作为主键避免跨租户重复。
- 避免额外的代理主键（如 serial ID）带来的冗余：当已有字段组合能保证唯一性时，添加自增 ID 会增加索引开销且无实际意义。
联合主键建模技巧与注意事项
合理使用联合主键不仅能提升语义清晰度，还能优化查询效率，但需注意建模方式：
- 控制主键列数量：尽量不超过 3 个字段。过多字段会导致索引体积变大，影响插入和连接性能。
- 注意列顺序：PostgreSQL 中联合主键的列顺序影响 B-tree 索引的使用效率。将最常用于等值查询或范围查询的列放在前面。
- 避免使用可变字段：主键应稳定不变。不要将可能被更新的列纳入主键，否则会引发外键级联更新问题。
- 外键引用需完整匹配：其他表若引用该联合主键，必须包含全部列，并保持相同顺序。
- 考虑查询模式：如果大多数查询只使用联合主键的一部分，可能更适合拆分为唯一约束 + 单独索引，或使用代理主键。
替代方案：唯一约束 + 代理主键
有时虽然业务上需要多个字段联合唯一，但仍可使用自增或 UUID 主键来简化开发。例如：
CREATE TABLE user_sessions ( id BIGSERIAL PRIMARY KEY, user_id INT NOT NULL, device_id VARCHAR(100) NOT NULL, login_time TIMESTAMP, UNIQUE (user_id, device_id) );
这种方式保留了应用层主键的便利性，同时通过唯一约束保障数据一致性。
基本上就这些。联合主键不是银弹，但它在恰当的场景下能让模型更贴近业务本质，减少冗余，提高效率。关键是理解数据关系和访问模式，做出权衡。
