list-compress-depth 是什么
Redis 的 list 由 quicklist 实现：一个逻辑列表被拆成多个节点，Redis 7 起节点内部用 listpack 存储。list-compress-depth 规定两端各保留多少个节点不压缩、中间节点用 LZF 压缩保存，默认值 0 表示完全不压缩。它换来的是内存：读中段元素要先解压，写入新节点时才按当时参数决定是否压缩。
基本信息
| 配置项 | list-compress-depth |
|---|---|
| 默认值 | 0（不压缩） |
| 单位 | 节点个数，N 表示两端各 N 个节点不压 |
| 生效方式 | CONFIG SET 动态生效，不回改已有节点 |
| 实现依赖 | quicklist（Redis 3.2 起） |
典型使用场景
- 超长列表当归档用：中段几乎不访问，压缩能省下可观内存
- 消息堆积型队列：两端进出频繁、中段堆积，压缩中间节点降低内存水位
- 日志类列表：只保留最近若干条并定期裁剪，老数据没有随机访问需求
- 内存吃紧的只读数据：写入后基本不再修改，压缩收益长期稳定
- 两端都热的场景：随机访问中段时压缩只增加 CPU，属于不该开的场景
配置与观察
配置与观察
redis-cli CONFIG GET list-compress-depth # 查看当前设置
redis-cli CONFIG SET list-compress-depth 1 # 两端各保留 1 个节点不压缩
redis-cli CONFIG GET list-max-listpack-size # 顺带确认单个节点的大小上限
redis-cli RPUSH big:list v1 v2 v3 # 新写入的节点才按新参数处理
redis-cli OBJECT ENCODING big:list # 应为 quicklist
redis-cli MEMORY USAGE big:list # 观察整体内存是否下降取值对照
| 取值 | 行为 | 判断建议 |
|---|---|---|
| 0 | 所有节点都不压缩 | 两端都热的短列表，保持默认 |
| 1 | 两端各 1 个节点不压，中间压缩 | 队列类场景的常用起点 |
| 2-3 | 两端保留更多热节点 | 两端访问频繁、中段偶尔访问 |
| 很大的值 | 实际等于不压缩 | 参数超过节点总数时一个节点也不会被压 |
压缩只作用于中段：列表节点总数少于两倍参数值时，其实没有任何节点被压缩，调参后先确认列表规模再判断收益。
list-max-listpack-size 决定每个节点能装多少元素（正值按元素个数、负值按字节数），它和压缩深度是两个维度：前者控制切分粒度，后者控制保留多少热节点。