键名就是模式声明
Redis 没有表结构，键名承担了「模式声明」的职责。用冒号分层（业务:对象:标识:字段）能让检索、批量清理、监控归类都有规律可循。键名本身也占内存：键的额外开销与键名长度近似线性相关，百万级键的实例把平均键名从 30 字节压到 15 字节，往往能省下几十 MB 常驻内存。在集群模式下，键名里的哈希标签还决定它落在哪个槽，命名方式同时影响数据分布。
基本信息
| 推荐格式 | 业务:对象:标识[:字段] |
|---|---|
| 示例 | order:20261012:1001:status |
| 长度建议 | 控制在几十字节以内 |
| 匹配语义 | SCAN 的 MATCH 使用 glob（* ? [ ]） |
| 集群影响 | 花括号内的内容决定槽位 |
典型使用场景
- 按业务域划分前缀，便于用 SCAN 按前缀巡检与统计键数量
- 用字段后缀（:status、:lock）区分同一对象的多种用途，避免一个键混装多种语义
- 集群下给需要原子操作的键加统一哈希标签，让它们必然落在同一个槽
- 按时间维度命名（如 order:20261012:*），让按日过期与按日清理变得可批量
- 缓存键带版本号（如 v2:user:1001），发版时改版本号即可整体换新，无需逐个删除
示例
示例
redis-cli SET order:20261012:1001:status paid # 冒号分层：业务:日期:标识:字段
redis-cli SET user:10001:profile '{"name":"a"}' # 对象与字段分开，不把 JSON 写进键名
redis-cli SCAN 0 MATCH 'order:20261012:*' COUNT 500 # 按前缀渐进遍历，不用 KEYS
redis-cli DBSIZE # 先看总量级
redis-cli -p 7000 CLUSTER KEYSLOT '{user:10001}:orders' # 确认哈希标签决定的槽位常见命名反模式
| 反模式 | 问题 | 建议 |
|---|---|---|
| 键名塞完整 JSON | 每个键多占几百字节，且键名不可读 | 键名用短标识，值里存 JSON |
| 大小写混用 | 同一对象出现两套键，统计口径混乱 | 统一小写 |
| 无分隔的长串 | 无法用前缀批量匹配 | 用冒号分隔层级 |
| 前缀过度集中 | 集群下易形成单分片倾斜 | 前缀按业务再细分 |
冒号只是团队约定而不是 Redis 语法，Redis 不解析键名结构；但正是这个约定让 MATCH 匹配、监控按前缀聚合、以及按前缀批量处理过期键变得可操作。