在数据库设计中，**主键（Primary Key）**用于唯一标识表中的每一行记录，选择一个合适的主键对性能、扩展性和数据质量都有很大影响。下面从原则、常见方案、对比和场景建议几个角度来说明。
id INT AUTO_INCREMENT PRIMARY KEY
优点
缺点
/user/1001）适用场景
id CHAR(36) PRIMARY KEY
优点
缺点
优化方案
UUIDv7（时间有序）BINARY(16) 存储64 位：时间戳 + 机器ID + 序列号
优点
缺点
适用场景
身份证号 / 邮箱 / 订单号
优点
缺点
建议
PRIMARY KEY (user_id, role_id)
优点
缺点
适用场景
| 场景 | 推荐主键 |
|---|---|
| 小型单体应用 | 自增 ID |
| 中型业务系统 | 自增 ID + 业务唯一索引 |
| 分布式 / 微服务 | Snowflake / UUIDv7 |
| 高并发写入 | Snowflake |
| 关系表 | 联合主键 |
| 强安全需求 | UUID（不暴露数量） |
❌ 用手机号、邮箱做主键
✅ 用其做唯一约束
❌ 主键频繁更新
✅ 主键一旦生成不应变更
❌ 分布式系统用自增 ID
✅ 用全局唯一 ID 生成器
优先使用与业务无关、稳定、全局唯一、索引友好的主键（如自增 ID 或 Snowflake ID）。
如果你愿意，可以告诉我：
我可以给你更具体的设计方案。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
