主键的设计规范与思考：从命名到生成策略的完整实践

最近在整理公司内部项目的数据库设计规范时，我重新审视了一下我们项目里“主键”的设计方式。看似简单的一个字段，背后其实藏着不少细节。 结合自己过去几个项目的踩坑经验，这篇文章就简单聊聊我在主键设计上的一些思考和落地方式。1. 主键名必须是 id这一点很多人可能已经习惯了，但还是要明确写下来：主键名统一叫 id。 好处其实很明显：

约定俗成，团队成员一看就懂。写 SQL、写实体类、写关联查询的时候不用再去记各种奇怪的主键名。ORM 框架、代码生成器等工具也能少一些特例判断。 统一命名虽然是小事，但在一个多人协作的大项目里，这种“低心智负担”的一致性其实非常重要。2. 外键名命名规则：[表名]_id我对外键名的要求是：外键字段名由目标表名去掉前缀、后缀后，加 _id 组成。 举个例子：

如果有张表叫 user_info，那引用它的外键字段就叫 user_id；如果有张表叫 sys_role_mapping，那对应外键就可以命名为 role_id。 这么命名的好处是：只看字段名就知道它关联的是哪个表的主键值。 不用再去查外键约束，也不用反推。数据表多的时候，这点能节省很多时间。3. 主键要可排序，但不要用数据库的自增这是我在项目中坚持的一条原则。 很多人觉得数据库的自增主键方便、省心，但我一般都会禁用它。原因有两个。

（1）安全问题设想一个很常见的接口：

GET /api/data/getById?id=123

理论上，用户应该只能访问自己有权限的数据。 但现实是，很多项目的接口层没有做严格的权限校验。 一旦主键是自增的，攻击者就可以轻易通过“猜id”的方式去访问到不属于自己的数据——因为自增是连续可预测的。 所以我宁愿用随机但可排序的主键，这样即使有人想“撞接口”，也几乎不可能猜中。

（2）迁移问题另一个问题是数据库迁移。 不同数据库的自增机制各不相同：

MySQL 是 AUTO_INCREMENT；PostgreSQL 是 SERIAL；Oracle 要用 SEQUENCE；甚至有些 NoSQL 数据库根本没有自增概念。 一旦项目需要跨数据库迁移，自增主键就是迁移的绊脚石。 要么得改DDL，要么得在代码层做适配，麻烦不小。 因此，我更倾向于使用分布式ID生成算法，比如雪花算法（Snowflake）。 它能保证全局唯一，同时又是时间有序的，排序、查询都方便。4. 主键值带业务前缀我非常推荐给主键加上一个业务标识前缀。 比如：

用户表：USR_1987708806273495041订单表：ORD_1987708806273495041产品表：PRD_1987708806273495041 这种方式有两个非常直接的好处：在调试或看日志时，一眼就能看出这是哪张表的数据；数据混合导出或跨系统对接时，也能避免不同表ID重复带来的混淆。 在大型项目里，尤其是有多模块或分布式系统的场景，这种区分度非常有帮助。5. 实际项目落地我在项目里是这么实现的： 定义一个注解，比如：

@IdPrefix("USR")

然后在 ORM 层（比如 MyBatis Plus 或 Hibernate）利用自动填充功能，在插入数据时：

读取实体类上的 @IdPrefix 注解；生成雪花算法ID；拼接成形如 USR_1987708806273495041 的字符串；自动赋值给实体类的 id 字段。 这样开发者在业务代码里完全不用关心主键生成逻辑，统一、规范、可控。所以，主键虽然只是数据库设计中的一个细节，但很多安全、迁移、维护问题，往往都能从“主键设计”里找到根源。 这套规范我自己在多个项目里都用下来比较舒服，也希望对你有启发。