怎样选择表的主键

选择数据库表的主键（Primary Key）是数据库设计中最核心的一步，直接影响数据完整性、查询性能、可维护性和扩展性。下面从原则、常见方案、避坑建议三个层面说明。

一、主键的基本原则

一个合格的主键应满足：

1. 唯一性（Unique）
   能唯一标识一行记录，不可重复。
2. 非空（Not Null）
   主键列不能有 NULL 值。
3. 稳定性（Stable）
   尽量不要修改；业务字段一旦变化，作为主键会很痛苦。
4. 简洁性（Small）
   越小越好，尤其是作为其他表外键时。
5. 可控性
   最好由系统生成，而非依赖外部业务输入。

二、常见主键类型及选择建议

1. 自增整数（AUTO_INCREMENT / SERIAL）

id BIGINT AUTO_INCREMENT PRIMARY KEY

优点

• 简单、性能好
• 索引体积小
• 天然有序，插入效率高

缺点

• 业务无意义
• 分库分表时可能冲突
• 暴露数据量（如 /user/123 可知用户数）

适用场景

• 绝大多数单体系统
• 内部系统、后台系统

✅ 最推荐默认方案

2. UUID / GUID

id CHAR(36) PRIMARY KEY

优点

• 全局唯一
• 适合分布式系统
• 不暴露业务信息

缺点

• 体积大（36 字符）
• 无序，索引碎片多
• 查询性能较差

优化方案

• 使用 UUIDv7（时间有序）
• 或用 BINARY(16) 存储

适用场景

• 微服务
• 多数据中心
• 不希望 ID 可预测

3. 业务主键（自然主键）

id_number VARCHAR(18) PRIMARY KEY  -- 身份证号
email VARCHAR(255) PRIMARY KEY

优点

• 有业务含义
• 查询直观

缺点

• 易变（邮箱可改、证件可换）
• 长度大
• 难以扩展

⚠️ 一般不推荐作为主键

✅ 可设为 唯一索引（UNIQUE）

4. 复合主键

PRIMARY KEY (user_id, role_id)

优点

• 适合多对多关系表
• 避免冗余字段

缺点

• 作为外键复杂
• 不利于后期扩展

适用场景

• 关联表（relation table）
• 明确且稳定的组合关系

5. 雪花算法（Snowflake ID）

64位：时间戳 + 机器ID + 序列号

优点

• 分布式唯一
• 大致有序
• 性能好

缺点

• 依赖时钟
• 实现稍复杂

适用场景

• 高并发
• 分布式系统

三、选择主键的实用建议

✅ 推荐做法

• 优先使用代理主键（无意义 ID）
• 使用 BIGINT 而非 INT（防溢出）
• 业务唯一字段加 UNIQUE
• 分布式系统用 UUIDv7 / Snowflake

❌ 不推荐做法

• 用手机号、邮箱、姓名做主键
• 用多个业务字段拼主键
• 用浮点数做主键
• 主键频繁更新

四、简单决策表

如果你愿意，可以告诉我：

• 使用的数据库（MySQL / PostgreSQL / Oracle）
• 是否分布式
• 表用途（用户、订单、日志等）

我可以帮你直接设计具体表结构。