作为常年和数据库设计打交道的开发者，我来聊聊业内的真实情况和普遍看法，刚好能解答你的疑问：

1. 行业普遍倾向：优先用id作为主键 #

在绝大多数OLTP业务场景（比如日常的电商、CRM这类业务系统），单表主键用id是绝对主流的选择。你可以观察到：

• MySQL、PostgreSQL这类主流数据库的官方示例，主键几乎都是id；
• Rails、Django这类主流ORM框架，默认生成的主键就是id；
• 大部分成熟开源项目的数据库设计，也遵循这个规则。

而带表名前缀的命名（比如order_id），业内几乎是专门用来标记外键的——比如用户表的主键是id，订单表里关联用户的字段就叫user_id，看到这个名字所有人都能立刻明白：这是关联用户表的外键。这也是你担心的点：如果把主键命名为order_id，很容易让其他开发者误以为这是个外键，反而造成理解混淆。

2. 两种命名的实质性差异：几乎无功能差异，全在协作成本 #

从数据库的功能层面来说，不管你用id还是table_id作为主键，数据库的性能、约束逻辑、索引效率都没有任何区别。两者的差异完全体现在可读性和团队协作成本上：

• 用id的好处：简洁、符合行业共识，新人接手项目不用额外学习特殊规则，跨表查询时用别名也很清晰（比如SELECT o.id, u.id FROM orders o JOIN users u ON o.user_id = u.id）；
• 用table_id的“优势”：可能在极少数跨表查询场景下不用写别名，但这种场景非常少见，而且带来的便捷远远抵消不了“容易混淆外键”的弊端。

3. 核心原则：一致性远大于选择本身 #

不管你最终选哪种命名方式，团队内部统一规范才是最重要的：

• 如果你的团队已经有了既定的数据库命名规则（比如要求所有主键都用table_id），那直接遵循现有规则即可，不用强行修改；
• 如果是新团队或者没有明确规则，强烈建议跟随行业主流：主键用id，外键用关联表名_id，这样能最大程度减少沟通成本，避免不必要的误解。

当然也有特殊场景例外，比如在数据仓库的维度表设计中，可能会用dim_user_id这类带前缀的主键，但这是针对数仓的特殊需求，不适合普通业务库。

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