
> 「高并发实测」系列第 7 篇（本站首发）。
>
> 网上流传的 Redis 优化口诀里，有一条特别流行：**"控制 field 数量保住 listpack"**。我测完 59 轮的结论是：这条口诀建立在一个混淆之上，而它让你忽视的另一个操作，差了 30 倍。

## 环境总表（先亮配置再亮数据）

| 项           | 值                                                                                              |
| ------------ | ----------------------------------------------------------------------------------------------- |
| Redis 版本   | **7.4.11** 单体（Docker，无持久化）                                                             |
| 压测客户端   | Java + Lettuce Pipeline，**c=16**（16 并发连接）**batch=50**（每次往返打包 50 条命令）          |
| 采样协议     | 每轮 5s 预热 + 10s 采样；公平对照用**交错配对**（见第三节）                                     |
| 编码验证     | 每轮 `OBJECT ENCODING` 逐轮回查                                                                 |
| 关键配置实测 | `hash-max-listpack-entries=512`、`hash-max-listpack-value=64`（7.4.11 默认，`CONFIG GET` 实测） |
| 复验         | 公平对照部分于发布前在 7.4.11 容器上用独立客户端（python 单连接）复测，见第三节                 |

> 环境/自建实验，绝对吞吐受客户端影响，**只看相对差距，别与 redis-benchmark 对比**。

## 〇、一分钟带走版

| 流行说法                                        | 实测结论                                                                                                                                     | 关键数字          |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| HSET 在 listpack 上快 20+ 倍，要"保住 listpack" | **数量假象**：那是 50 field vs 500 field 的差距，混了两个变量；**修正阈值语义后的公平对照（只差 1 条、同值长）下 hashtable 反超 +8.8%~+38%** | 交错配对 5 轮中位 |
| SMEMBERS / HGETALL "慢一点而已"                 | **大结果集的全量读取是数量级差距**：本组配置下 **约 34 倍**（476K vs 14K ops/s）——由成员数、成员长度、编码、响应量共同作用                   | 476K vs 14K ops/s |
| Set 应该存字符串                                | **本组配置下整数集合各项吞吐更高**（SREM +46%、SRANDMEMBER +102%）——但成员数/内容不同，不能单独归因于 intset 编码                            | 21 轮数据         |
| ZADD 在大 ZSet 上会慢？                         | **500m skiplist 反而比 50m listpack 快 11%**——非公平对照，机制解释降为可能因素                                                               | 139K vs 126K      |

一句话：**"刻意保小"不是银弹；真正要防的是大结果集的全量读取——那是数量级的差距。**

## 一、背景：编码是"凑"出来的，且单向不可逆

Redis 的内部编码**由数据自动决定，无法显式指定**。想测某个编码，只能靠 member/value 的类型、数量、长度去"凑"，然后每轮用 `OBJECT ENCODING` 验证。

三个必须先说清的性质：

1. **转换单向不可逆**：listpack 转 hashtable 后，删数据也不会转回来。
2. **阈值语义要精确**：以 Hash 为例，转换由**两个配置共同触发**——`hash-max-listpack-entries`（7.4.11 默认 **512**）和 `hash-max-listpack-value`（默认 **64B**）。field 数**超过** 512、或任一 value **超过** 64B，都会转 hashtable。网上资料常把 **128** 当成 Hash 的阈值——那是 **ZSet 的 listpack 条目阈值**，本文写作时就踩了这个混淆（详见第三节与文末勘误链）。
3. **Set 的编码与内容天然耦合**：整数成员才可能 intset，字符串成员不可能 intset——**Set 无法做到"同内容只换编码"的公平对照**，这是 Set 编码测试的方法论边界。

## 二、假象层：HSET"快 23 倍"是怎么来的

| 操作 | listpack（50 field） | hashtable（500 field） | 差距       |
| ---- | --------------------:| ----------------------:| ----------:|
| HSET | 碾压                 | 低                     | **+2260%** |

50 field 的 listpack 对 500 field 的 hashtable，HSET 快 2260%——折合 23 倍。"listpack 性能远超 hashtable"的说法多半源于这类对比。

**但这个对照混了两个变量**：编码不同，**field 数量也差 10 倍**。listpack 赢，有多少是编码的功劳、有多少只是"它只有 50 条"？

## 三、公平对照：把变量拆干净之后

要公平，必须**只让编码变**。Hash 可以做到：**固定 value 长度（40B，≤64B 不触发长度转换），把 field 数压到阈值两侧，让"条目数"单独触发编码转换**：

- 配置 A：`hash-max-listpack-entries=128`（CONFIG SET 显式设定）→ 128f = listpack，129f = hashtable
- 配置 B：`hash-max-listpack-entries=512`（7.4.11 默认）→ 512f = listpack，513f = hashtable

两组都用 `OBJECT ENCODING` 逐侧验证编码。采样协议升级为**交错配对**（每轮交替采样两个配置、每两轮换顺序，按轮算比值取中位）——因为共享宿主上同一配置前后两轮能差 4 倍，非交错的单会话名次不可信（系列第 6 篇的方法论，在这里被迫实战了一次）。

| 对照                          | listpack 侧 | hashtable 侧 | 逐轮比值（listpack/hashtable）        | 中位      |
| ----------------------------- | -----------:| ------------:| ------------------------------------- | ---------:|
| A：阈值 128，128f vs **129f** | 基线        | 基线         | 0.797 / 1.000 / 0.883 / 1.117 / 0.919 | **0.919** |
| B：阈值 512，512f vs **513f** | 基线        | 基线         | 0.723 / 0.468 / 0.473 / 1.068 / 0.890 | **0.723** |

**两个阈值下，hashtable 侧都更快**：A 组 hashtable 快约 8.8%，B 组（512 条的 listpack，O(N) 扫描更贵）快约 38%。逐轮比值在 0.47~1.12 间波动——漂移真实存在，交错配对把它的方向性洗了出来。

**结论要克制地说**：在"指定版本（7.4.11）、指定配置、HGET 随机 field 负载、40B value"的条件下，**临界点之后的 hashtable 吞吐高于 listpack，且条目越多差距越大**。"刻意分片/限容去保 listpack"在本次观察里没有收益——但分片会改变键数量、网络往返和内存占用，本文没测那些，不把这句话外推成普遍规律。

> **口径说明（客户端不同）**：本节公平对照由 **python 单连接 pipeline（batch=50）** 采集——与 47 轮主数据的 Java Lettuce c=16 **不是同一个客户端**，绝对吞吐不可比。但本节只引用**比值**，不引用绝对值——比值与方向在不同客户端间可比。

![fig1-公平对照.png](https://developer.qcloudimg.com/http-save/yehe-12890655/4691a34297809b3b47583b849f967635.png)
## 四、Set：整数集合更高，SMEMBERS 差了 30 倍——但归因要拆开

Set 的编码阶梯（以 7.4.11 实测为准）：全整数成员走 **intset**（条目数阈值 `set-max-intset-entries`=512）；字符串成员走 listpack/hashtable（条目数阈值依 `set-max-listpack-*` 配置，本文以每轮 `OBJECT ENCODING` 实测为准）。21 轮数据：

| 操作         | intset（50 整数） | listpack（50 字符串） | hashtable（500 长串） | intset vs hashtable |
| ------------ | -----------------:| ---------------------:| ---------------------:| -------------------:|
| SADD         | 364K              | 346K                  | 311K                  | +17%                |
| SISMEMBER    | 379K              | 345K                  | 329K                  | +15%                |
| SREM         | 448K              | 449K                  | 307K                  | +46%                |
| SRANDMEMBER  | 522K              | 530K                  | 258K                  | +102%               |
| **SMEMBERS** | 476K              | 481K                  | **14K**               | **约 34 倍**        |

**先说这组数据的边界**：intset 侧是 50 个小整数，hashtable 侧是 500 个 200B 长串——**成员数差 10 倍、成员长度和响应字节数也差很多，编码只是差异之一**。而且 Set 的编码与内容天然耦合（整数才可能 intset），**无法做"同内容只换编码"的公平对照**——这是 Set 编码测试的方法论边界，无法绕过。

所以结论只能这样下：**在本次"小规模整数集合 vs 大规模长字符串集合"的配置下，整数集合各项吞吐全面更高**；由于成员数与内容不同，**不能单独归因于 intset 编码**（"二分查找"也只能解释查询类操作）。要严格比较编码，需要保持成员数、内容和负载相同、仅用配置触发编码——Set 做不到，Hash 可以（第三节）。

**SMEMBERS 的 34 倍同理**：它是"成员数 × 成员长度 × 编码 × 响应量 × 客户端解码"的共同结果，不能单独归因于 hashtable 编码。但**生产动作不受归因影响**：无论差距来自哪几成，大结果集的全量读取（SMEMBERS/HGETALL）在单线程 Redis 上就是数量级事件（avg 54.7ms——口径：pipeline 批内单命令平均响应时间，客户端观测值；c=16 × batch=50 下在途约 800 条，不是单请求 RTT）——**改 SSCAN/HSCAN，或按业务分片**。

> SSCAN/HSCAN 的语义要说准：**COUNT 只是提示**，不保证每次恰好返回固定数量；完整迭代仍是 O(N)，迭代过程中可能遇到重复成员。它降低的是"单次全量返回"的压力，不是总工作量，更不是硬性时间上限。

![fig2-SMEMBERS.png](https://developer.qcloudimg.com/http-save/yehe-12890655/9d17e01a2b2bcaf1c0284856a50cc12e.png)
## 五、ZSet：skiplist 快 11%——先说明这不是公平对照

**128 个 member 未触发 skiplist 转换**（本节最重要的前置事实），所以下面是"50m listpack vs 500m skiplist"的**规模混比**：

| 操作     | listpack（50m） | skiplist（500m） | 差距              |
| -------- | ---------------:| ----------------:| -----------------:|
| **ZADD** | 126K            | **139K**         | **skiplist +11%** |
| ZSCORE   | 300K            | 299K             | 接近              |
| ZRANGE   | 188K            | 188K             | 接近              |
| ZINCRBY  | 112K            | **116K**         | skiplist +4%      |

在规模差 10 倍的前提下，ZADD 仍快 11%——**skiplist 的 O(logN) 定位是可能因素之一，但这组数据不能独立量化它的贡献**。能确定的只有：**大 ZSet 的高并发 ZADD 没有因为"离开 listpack"而变慢**。临界点附近 listpack 是否反超（Hash 上观察到的现象）在 ZSet 上**没测到**（128m 未触发转换），不下结论。

![fig3-ZSet与原则.png](https://developer.qcloudimg.com/http-save/yehe-12890655/be9393e38c634c41356a0462ddf64e06.png)
## 六、横向共性：真正要防的是"全量读取"

| 维度           | String       | Hash                                     | ZSet           | Set                   |
| -------------- | ------------ | ---------------------------------------- | -------------- | --------------------- |
| 小数据最优     | embstr       | listpack                                 | listpack       | intset/listpack       |
| 临界点反超     | —            | **hashtable +8.8%~+38%（本文公平对照）** | 未触发，未测到 | 混变量，未单独归因    |
| **真正的大坑** | raw 反复拼接 | **大结果集 HGETALL**                     | —              | **大结果集 SMEMBERS** |

四条生产原则：

1. **编码不可强求**：小数据自动落进紧凑编码，是福利不是任务；
2. **"刻意保小"在本次观察中没有收益**：临界点之后大编码反超（Hash 公平对照 +8.8%~+38%），且 7.4.11 的默认阈值已让"保 listpack"的适用范围比流传说法更窄；
3. **真正要防的是大结果集全量读取**（HGETALL/SMEMBERS/大 value 反复拼接）——数量级差距（本组约 34 倍），改 SSCAN/HSCAN（注意迭代语义）或分片；
4. **整数别存成字符串**：本次配置下整数集合全面更高——虽不能单独归因编码，但这个动作零成本。

## 七、勘误链：这篇稿子自己被打脸三次（写出来给后来人）

本文从初稿到发布，经历了三次实质性修正——全部是"写了→对照源数据/实测→发现错→改"的循环，按时间顺序列出：

1. **阈值混淆**：初稿沿用了流传说法"Hash 的 listpack 阈值是 128"。复验时 CONFIG SET 128 后灌 128f，`OBJECT ENCODING` 返回的**还是 listpack**——查 `CONFIG GET` 才发现 7.0/7.4 的 Hash 默认阈值都是 **512**，128 是 **ZSet** 的阈值。原场景 11 文档里"500 长串转 hashtable"的真实触发条件是 **value > 64B**（长度），不是条目数。
2. **归因过度**：初稿把 SMEMBERS 的 34 倍差距归因于"hashtable 编码 + dict 遍历逐条分配"。审稿指出该对照同时改变了成员数、成员长度和响应量，且无分配器/profile 证据——已降级为"共同作用"，生产建议保留但归因撤回。
3. **对照不公平**：ZADD 的 +11% 同样是 50m vs 500m 的规模混比——保留实测数据，机制解释降为"可能因素之一"。

**这三次修正的教训是同一句话：结论的置信度，取决于你把变量拆得多干净。**

## 八、局限（发前认账）

- 所有数据为单会话批次（每配置 5s 预热 + 10s 采样），绝对吞吐受客户端（Pipeline 打包/序列化）压低，**只看相对差距，别与 redis-benchmark 对比**
- **公平对照只在 Hash 上完成**（count 触发 + 同值长 40B + 交错配对 5 轮）；Set 因编码与内容耦合无法做同内容对照，ZSet 的 128m 未触发转换
- 共享宿主的会话级漂移显著（同配置前后两轮可差 4 倍），交错配对只消除方向性偏差，**逐轮比值仍有 0.47~1.12 的波动**
- 未测 jemalloc/libc 分配器差异与 lazyfree 配置
- 未测集群/分片形态（跨槽影响另见系列场景 7）；"分片"建议仅指大结果集拆分方向
- String 的 12 轮数据来自系列第 1 篇（[系列第 1 篇](https://blog.csdn.net/davidlia)），本文未重跑；44/128/512 阈值随版本与配置变化，**以 `CONFIG GET hash-max-listpack-*` + `OBJECT ENCODING` 实测为准**

## 九、十问十答

**Q1：为什么 50f 的 HSET 比 500f 快这么多？**
规模差 10 倍是主因，编码是次因——所以那个 23 倍不能当编码结论用。

**Q2：Hash 的 listpack 阈值到底是 128 还是 512？**
7.0/7.4 默认都是 **512**（`hash-max-listpack-entries`），128 是 ZSet 的（`zset-max-listpack-entries`）。另外 value 超 64B（`hash-max-listpack-value`）也会触发转换——两个条件任一满足即转。

**Q3：ZSet 的阈值是多少？**
`zset-max-listpack-entries`=128、`zset-max-listpack-value`=64。本文 128m 未触发转换与该配置一致。

**Q4：SMEMBERS 慢 34 倍，是编码的锅吗？**
不全是。成员数、长度、编码、响应量、客户端解码共同作用——但生产结论一样：大结果集别全量读。

**Q5：要不要故意把成员存成整数走 intset？**
本次配置下整数集合吞吐全面更高，且零成本——但注意这是混变量观察，别期待精确倍数。

**Q6：SSCAN 能彻底解决大集合问题吗？**
不能彻底——它把"一次大响应"拆成"多次小响应"，降低单次压力；COUNT 是提示非保证，完整迭代仍 O(N)，可能重复。总工作量不变。

**Q7：Redis 7.4 在编码上有什么变化？**
本文实测范围内 Hash/Set 的转换行为与 7.0 一致，**但默认阈值以你的版本为准**——本文最大的教训就是"背阈值"这件事本身不可靠。

**Q8：为什么要交错配对采样？**
共享宿主上同配置前后两轮能差 4 倍（实测 60775 vs 14310）。交替采样+按轮算比值，让漂移作为共模被抵消——否则你会把"宿主抖了一下"当成"编码快了 4 倍"。

**Q9：分片能解决大结果集吗？**
能缓解（每个 key 的成员少了），但引入键数量、网络往返、内存布局的新变量——本文未测分片本身，只给方向。

**Q10：数据怎么复现？**
文内所有参数已给全（版本、CONFIG 值、c/batch、采样协议、交错配对）。压测工程后续整理开源；欢迎按自己的环境复测并贴回结果。

## 系列目录

**「高并发实测」系列（本站陆续上架，历史篇目发布后在此回填链接）**

| 篇  | 主题                                        |
|:---:| ------------------------------------------- |
| 1   | Redis String 三种编码实测：别再死背 44 字节 |
| 2   | 把最重的库改回同步，QPS 反而涨了 38%        |
| 3   | Agent 工程化实测：可观测/舱壁/熔断          |
| 4   | RAG 评测三层反转                            |
| 5   | AI Agent 落地全景                           |
| 6   | 线程池到底设多大？4 台机器实测              |
| 7   | 本文：Redis 编码横向实测                    |
| 8   | 一条 ALTER 拖死全表（预告）                 |


网上流传的 Redis 优化口诀里，有一条特别流行："控制 field 数量保住 listpack"。我测完 59 轮的结论是：这条口诀建立在一个混淆之上，而它让你忽视的另一个操作，差了 30 倍。

Redis 编码压测 59 轮：HSET 快 23 倍是假象，SMEMBERS 慢 30 倍是真的（含 7.4.11 复验注记）

Redis 编码压测 59 轮：HSET 在 listpack 上快 23 倍是数量假象，公平对照（同值长、只差 1 条）下 hashtable 反超 +8.8%~+38%；SMEMBERS 在大集合上慢 34 倍才是真差距。含 hash-max-listpack-entries 阈值勘误（128 是 ZSet 的）、SSCAN 语义、7.4.11 复验注记与生产速查。全部数据可复算。

数据库

后端

测试

网上流传的Redis优化口诀“控制field数量保住listpack”建立在混淆之上：实测显示，listpack快20多倍源于50field对500field的规模差，而非编码本身。公平对照下hashtable反超8.8%~38%。真正数量级差距在大结果集全量读取，本组约34倍，应改用SSCAN/HSCAN或分片。

容器

Docker

Python

Redis

Java

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis 编码压测 59 轮：HSET 快 23 倍是假象，SMEMBERS 慢 30 倍是真的（含 7.4.11 复验注记）-腾讯云开发者社区-腾讯云

Redis 编码压测 59 轮：HSET 快 23 倍是假象，SMEMBERS 慢 30 倍是真的（含 7.4.11 复验注记）

Redis 编码压测 59 轮：HSET 快 23 倍是假象，SMEMBERS 慢 30 倍是真的（含 7.4.11 复验注记）

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐