键名也是内存
每个键都会完整保存键名，键名本身就是内存的一部分。冗长前缀加嵌套命名在键数到达百万级时，占用会变得可观；统一缩写前缀能省下实实在在的净收益。但缩写牺牲可读性，命名规范要在项目初期就预留演进空间。
基本信息
| 实测方式 | MEMORY USAGE 的返回值已含键名开销 |
|---|---|
| 优化手段 | 缩短前缀、统一命名规范 |
| 权衡 | 可读性与内存的平衡 |
| 收益量级 | 百万级键时每键省几十字节即可观 |
典型使用场景
- 缓存类数据键数量大、结构统一，适合压缩命名
- 会话与令牌类高频短生命周期键，键名占更突出
- 键数量已进入百万级，内存水位吃紧
- 新项目立项时制定键命名规范
- 现状盘点：抽样估算键名占总内存的比例
对比与估算
对比与估算
redis-cli MEMORY USAGE user:profile:settings:1001 # 长键名的实际占用
redis-cli MEMORY USAGE u:p:1001 # 缩写后的占用，直接对比
redis-cli DBSIZE # 键总数，用于估算总收益
redis-cli --scan --pattern 'user:profile:*' | head -50 # 抽样看该类键的规模
# 注意：Redis 7 起 DEBUG 默认关闭，需放开 enable-debug-command
redis-cli DEBUG OBJECT user:profile:settings:1001 # 看键的内部编码与序列化长度
# 估算口径：单键省下的字节数 乘以 键数量命名方式取舍
| 命名方式 | 示例 | 取舍 |
|---|---|---|
| 完整可读 | user:profile:1001 | 自解释，但键名偏长 |
| 缩写前缀 | u:p:1001 | 省内存，需一份命名对照表 |
| 加类型前缀 | s:user:1001 | 便于运维识别，增加少量长度 |
| 含租户信息 | t1001:user:1 | 隔离清晰，但重复前缀会放大总量 |
改命名方案等于全量迁移（旧键新键并存或双写），制定规范时就要考虑未来是否要加租户、版本等维度，避免后期大改。
安全敏感数据不要为了省内存把键名压到难以审计的程度。键名过短会让排障和权限核对都变困难。
MEMORY USAGE 的估算本身带采样误差，做键名优化的收益估算时，看量级即可，不必追求字节级精确。