复合主键可唯一标识记录时，哪种主键方案更优？

这是个数据库设计里非常典型的场景，我结合实际项目经验来拆解两种方案的优劣势，以及为什么大家更倾向于用额外ID当主键。

方案1：用（单词ID + 释义内容）作为复合主键 #

优点 #

• 天然保证唯一性：不需要额外加约束，复合键本身就能确保同一个单词不会有完全重复的释义记录（当然，如果业务允许重复释义，这反而会变成限制）。
• 节省少量存储空间：少了一个独立ID字段，对超大规模数据来说能省一点点空间，但现在存储成本极低，这点优势几乎可以忽略。

缺点 #

• 业务变动时的维护灾难：如果后续需要修改释义内容（比如修正拼写、优化表述），主键本身就会改变。要是这个释义还关联了其他表（比如例句表、同义词关联表），所有关联的外键都得跟着改，操作风险极高且非常繁琐。
• ORM框架支持不友好：现在大部分项目都用ORM框架（比如JPA、Django ORM、MyBatis-Plus），复合主键的处理逻辑比单字段主键复杂得多，需要额外编写实体类、自定义序列化规则，很容易引入bug。
• SQL编写繁琐：查询、更新、关联查询时都要同时带上两个主键字段，比如WHERE word_id = 123 AND definition = 'xxx'，不仅代码变长，还容易写错。
• 扩展性差：如果后续要给释义表加新的关联关系（比如用户点赞记录、收藏记录），外键需要同时存储word_id和definition，冗余度高，还会让关联表的结构变得复杂。

方案2：新增独立ID作为主键，单词ID作为外键 #

优点 #

• 主键稳定性极强：不管释义内容怎么修改，ID始终不变，关联其他表时完全不用担主键变动带来的连锁反应。
• ORM框架友好：所有主流ORM都对单字段主键有完美支持，实体类编写、CRUD操作都非常省心，几乎不需要额外处理。
• 开发效率高：SQL编写简单，只用WHERE id = 456就能定位记录，调试、维护都更轻松。
• 扩展性极佳：后续新增任何关联需求（比如关联例句、点赞记录），只需要用这个独立ID作为外键即可，结构清晰，冗余度低。
• 数据库性能更优：单字段主键的索引比复合索引更高效，尤其是在大数据量下的查询、排序、分页操作，数据库的优化成本更低。

缺点 #

• 多占用一点存储空间：多了一个ID字段（通常是int或bigint，4-8字节），但对于现代数据库来说，这点空间消耗完全可以忽略不计。
• 需要维护ID生成规则：比如自增ID、UUID、雪花ID等，但这些都是数据库或框架原生支持的，配置一次就不用管了，没有额外的维护负担。

为什么实际项目里更常用独立ID？ #

总结下来，核心原因有这几个：

• ORM框架的普及：复合主键在ORM里的处理成本太高，开发者为了避免麻烦，自然会选择单字段主键。
• 业务需求的不确定性：实际项目中需求经常变动，今天可能只需要存释义，明天可能要加例句、点赞、版本历史，独立ID的扩展性完全能应对这些变化，而复合主键会把自己逼进死胡同。
• 开发效率与维护成本：单ID主键写代码更快，出错概率更低，后续维护也更简单，团队协作时的沟通成本也更小。
• 数据库性能的隐性优势：单字段主键的索引更高效，尤其是在高频查询的场景下，性能差距会逐渐显现。

举个实际场景的例子：假设你后来要做一个“用户收藏释义”的功能，用独立ID的话，收藏表只需要存user_id和definition_id；如果用复合主键，收藏表就得存user_id、word_id、definition，不仅冗余，而且如果释义内容修改了，收藏记录里的definition也得同步更新，这完全是没必要的额外工作。

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