为何要使用复合主键，而非单列主键加复合列唯一约束？

两种方案各自的优势 #

复合主键的优势 #

• 存储与查询性能更优：InnoDB等主流数据库中主键默认是聚簇索引，直接以业务复合列作为主键时，数据按复合列顺序组织存储，不需要额外占用单列主键的索引空间。如果查询条件命中复合主键的前缀规则，可直接走聚簇索引无需回表，性能表现更好。
• 索引维护开销更低：不需要单独为复合业务列新建唯一索引，表整体索引数量更少，数据写入时的索引更新成本更低。
• 语义贴合业务逻辑：如果业务上本身就是通过多列组合确定唯一行记录，复合主键的设计更贴合第三范式，不会引入无意义的单列主键冗余。

单列主键+复合唯一约束的优势 #

• 改造成本极低：你当前系统已经基于单列主键搭建，只需新增唯一约束即可实现复合列的唯一性校验，不需要调整任何关联表结构、历史SQL和上层业务代码，几乎没有上线风险。
• 关联逻辑更简洁：多表关联时外键只需存储单个ID列，JOIN语句只需关联单个ID字段，既降低了SQL编写复杂度，也避免了多列关联时条件写错的问题。
• 生态兼容性更好：绝大多数ORM框架、低代码工具、缓存组件对单列主键的支持度远高于复合主键，批量操作、缓存键生成、参数传递都只需要处理单个ID值，适配成本更低。
• 业务迭代更灵活：如果后续业务规则变化，复合列的唯一性校验逻辑需要调整（比如新增/减少校验列），只需要修改唯一约束即可，不需要调整主键定义，更不需要修改所有关联表的外键结构，改造成本和风险都极低。

方案选择建议 #

• 优先选择单列主键+复合唯一约束的场景：
  • 现有系统已经大量使用单列主键，改复合主键需要调整的关联表、历史SQL、业务代码规模大，改造成本远高于收益（你当前的场景就属于这类，没有特殊需求优先选这个方案）。
  • 业务规则存在调整可能，复合列的唯一性逻辑未来有变动风险。
  • 项目用到ORM框架、低代码平台，对复合主键的支持不完善。
  • 该表关联的其他表数量多，用单列主键可以大幅简化关联逻辑。
• 可以考虑选择复合主键的场景：
  • 属于全新开发项目，没有历史包袱，且业务上复合列的唯一性规则非常稳定，长期不会调整。
  • 该表很少与其他表做关联，或者关联查询时本身就会携带复合主键的所有列作为条件，不需要简化关联逻辑。
  • 对表的写入、查询性能有极致要求，需要尽可能压缩索引存储开销、减少回表操作。

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