一个键都由什么组成
一个键占的内存远不止值本身：除了键字符串与值对象，还有主字典的表项与散列桶、带过期时间时的过期表条目，以及内存分配器按尺寸对齐带来的损耗。理解这个构成，才能解释「明明只存了几十兆数据，实例却占了几百兆」。
基本信息
| 主要组成 | 键字符串、值对象、字典表项、过期表条目、对齐损耗 |
|---|---|
| 实测工具 | MEMORY USAGE 可直接测量单个键 |
| 优化方向 | 缩短键名、合并小值、控制 TTL 键数量 |
| 观测辅助 | OBJECT ENCODING 看编码是否紧凑 |
典型使用场景
- 容量估算时解释实际占用远大于数据量
- 键数量巨大的场景评估缩短键名的收益
- 排查「删了数据内存却不降」的困惑
- 制定键名规范时平衡可读性与长度
- 核对单个键的实测占用与业务预期是否一致
实测与拆解
实测与拆解
# 实测单个键的实际占用（含结构开销）
redis-cli MEMORY USAGE user:profile:1001
# 看编码方式：小对象用紧凑编码，开销明显更小
redis-cli OBJECT ENCODING user:profile:1001
# 带 TTL 的键会额外占用过期表条目
redis-cli TTL user:profile:1001
# 从实例层面看数据集与开销的比例
redis-cli INFO memory | grep -E 'used_memory_human|used_memory_dataset|used_memory_overhead'开销构成读法
| 构成 | 说明 | 影响 |
|---|---|---|
| 键字符串 | 键名对象本身 | 键名越长，这份固定开销越大 |
| 值对象 | 值与编码方式 | 小对象用紧凑编码更省内存 |
| 字典表项 | 主字典中的条目与散列桶 | 每个键都有一份 |
| 过期表条目 | 只有带 TTL 的键才产生 | 键数量大时不可忽略 |
| 分配对齐 | 分配器按尺寸分级分配 | 实际占用通常大于理论值 |
在十万级小键的场景里，结构开销可以接近甚至超过数据本身；此时缩短键名、减少键数量（例如把小值合并进 hash）的收益往往比压缩值更直接。
按「值大小乘以键数量」估算容量会系统性偏低；容量规划应当用 MEMORY USAGE 抽样实测再加结构开销，并留出余量。