数据库主键（Primary Key）的设计直接关系到数据的唯一性、查询性能、可扩展性以及业务灵活性。下面从原则、常见方案、对比与最佳实践几个层面系统说明。
id BIGINT AUTO_INCREMENT PRIMARY KEY
优点
缺点
适用场景
id CHAR(36) PRIMARY KEY
优点
缺点
优化方案
BINARY(16) 存储 UUID时间戳 + 机器ID + 序列号
优点
缺点
适用场景
PRIMARY KEY (order_no)
优点
缺点
建议
PRIMARY KEY (user_id, role_id)
优点
缺点
建议
| 场景 | 推荐方案 |
|---|---|
| 单体应用 | 自增 BIGINT |
| 微服务 | Snowflake / UUIDv7 |
| 分库分表 | Snowflake |
| 日志表 | 时间 + 自增 |
| 关系表 | 联合主键或代理主键 |
| 对外 API | 不暴露自增 ID |
✅ 推荐组合方案
BIGINT 主键（Snowflake）
业务字段加 UNIQUE
✅ 不要
✅ 对外安全
order_no、codeid如果你愿意，我可以根据你的：
给你一套具体可落地的主键设计方案。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
