在数据库中，“key（键）”的优化通常围绕性能、空间、可维护性三个核心目标展开。不同数据库（关系型 / NoSQL）对 key 的处理方式不同，下面按常见场景系统说明。
BIGINT（自增 / 雪花ID）UUID（无序、占用大、索引碎片多）INDEX(a, b, c)
-- 可用：a / a,b / a,b,c
-- 不可用：b / c
INDEX(a)
INDEX(a, b) -- 前者冗余
SELECT id, name FROM user WHERE age = 18;
INDEX(age, name)
业务:模块:唯一标识
user:profile:10001
: 或 _）user:10001:order:1
user:10001:order:2
_id 默认 ObjectId（有序、性能好）✅ 短
✅ 稳定
✅ 高区分度
✅ 可扩展
❌ 不长、不变、不重复、不冗余
| 问题 | 后果 |
|---|---|
| UUID 做主键 | 索引碎片、性能下降 |
| 长字符串做 Redis key | 内存浪费 |
| 联合索引顺序错 | 索引失效 |
| 业务字段做主键 | 数据维护困难 |
如果你能告诉我：
我可以给你针对性的优化方案或示例。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
