为何应使用非标识关系？SQL教师偏好各表设唯一ID的益处

为什么优先用非标识关系+独立唯一ID #

• 数据修改更灵活：标识关系里子表主键依赖父表主键，要是父表主键得调整（比如业务规则变更要修改编码），子表所有关联的主键都得跟着改，操作繁琐还容易引发数据不一致问题。用独立唯一ID（比如自增INT、UUID）的话，父表主键变动完全不影响子表，数据结构稳定性更强。
• 业务与数据结构解耦：标识关系会把业务逻辑绑定到主键上，比如用用户ID+商品编码作为订单子表的复合主键，哪天商品编码规则变动，主键结构也得跟着改。独立唯一ID不带业务意义，只负责唯一标识数据，业务怎么迭代都不用动主键结构，扩展性更好。
• 关联和索引更简单：用复合主键当外键关联时，SQL得写多个字段的条件，比如WHERE order_item.user_id = user.id AND order_item.sku = product.sku，不仅麻烦还容易出错。单一唯一ID做外键的话，关联条件只需要一个字段，SQL更简洁，而且单一字段的索引维护成本低，查询效率更稳定。
• 存储空间更高效：如果复合主键包含多个字符串字段，占用的存储空间会很大，索引文件也会随之膨胀，拖慢查询速度。独立唯一ID一般是整数或者短UUID，占用空间小，索引性能更优。

父子关系（标识关系）的性能表现 #

父子关系在极少数特定场景下可能有一点性能优势，比如查询子表数据时，因为主键里包含父表ID，有时候能减少一次关联查询的开销，但这点优势完全抵不上它带来的维护成本：

• 跨表关联时，复合主键的关联逻辑更复杂，数据库优化器生成的执行计划往往不如单一主键高效。
• 随着数据量增长，复合主键的索引更容易出现碎片化问题，维护索引的开销会逐渐增大，反而拖慢整体性能。
• 目前主流数据库对单一主键的索引优化已经非常成熟，独立唯一ID的查询性能完全能覆盖绝大多数业务场景，甚至比复合主键更稳定。

总的来说，采用非标识关系加独立唯一ID的方案，在可维护性、扩展性上的优势远超过父子关系那点有限的性能收益，这也是行业内的通用最佳实践。

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