hgetall在hash字段超几百个后明显变慢，因其需一次性加载全部field-value到内存并序列化返回，无法中断或流式传输，字段越多延迟越不可控，甚至阻塞redis主线程；推荐用hscan替代，通过游标分批迭代，避免内存暴涨和cpu尖峰。
HGETALL 在 Hash 字段超几百个后就会明显变慢，不是 Redis 抗不住，而是它必须一次性把全部 field-value 加载进内存、序列化、再发给客户端——这个过程无法中断、不能流式返回，字段越多，延迟越不可控，甚至卡住主线程。
为什么 HGETALL 一到大 Hash 就卡住
Redis 的 HGETALL 是原子命令，内部实现是先遍历整个 Hash 结构，再打包成一个大数组返回。哪怕 Hash 总数据才 2MB，只要字段数过万，HGETALL 就可能触发毫秒级延迟；实测在 50 万 field 的 Hash 上，响应常超 2 秒，且伴随 CPU 尖峰和客户端 OOM 风险。
根本问题不在数据量，而在设计：它不支持分批、不提供游标、不释放中间内存。一旦开始执行，就得干完再交差。
- 字段数 > 512 或任意
value长度 > 64 字节时，Hash 编码可能已从ziplist升级为hashtable，内存开销翻倍，HGETALL序列化压力更大 -
HGETALL返回的是完整副本，客户端解析时还要额外分配内存，容易成为瓶颈点 - 慢日志里反复出现
HGETALL超时，基本可断定是某个 Hash 在“悄悄膨胀”
HSCAN 替代 HGETALL 的正确写法
HSCAN 不是分页，是游标驱动的增量迭代。每次调用返回一批数据 + 下一个游标值，直到游标返回 0 才算结束。它不阻塞、不爆内存、可中断续扫。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 第一次必须传
cursor=0，后续调用必须用上一轮返回的cursor值，硬编码或忽略会导致漏数据 -
COUNT是提示值，不是硬限制；生产环境建议设为100～500，太小请求爆炸，太大单次响应包过大（实测COUNT=500在千兆内网综合效率最高） - 返回结构是
[cursor, {field1: value1, field2: value2, ...}]，注意cursor是字节串（如b'0'），比较时要用cursor == b'0'，不是cursor == '0' - Python 示例：
cursor = b'0'<br>while cursor != b'0':<br> cursor, data = r.hscan('user:1001', cursor=cursor, count=500)<br> for field, value in data.items():<br> process(field.decode(), value.decode())
HSCAN 实际使用中容易踩的坑
HSCAN 看似简单，但线上出问题往往不是不会用，而是忽略了运行时约束和边界条件。
- Hash 在遍历过程中被并发修改（新增/删除 field），
HSCAN可能重复返回某些 field，也可能跳过部分 field——这不是 bug，是设计使然；强一致性场景需业务层加版本号或去重逻辑 - 未设置客户端超时，网络抖动或 Redis 暂停响应时，会卡死在某次
HSCAN调用上，建议设socket_timeout=3s并配合指数退避重试 - 盲目增大
COUNT（如设为10000）反而降低吞吐：单次响应序列化/网络传输/反序列化成本陡增，还可能触发 TCP 分片 - 未关闭 pipeline 或连接复用，高频
HSCAN会快速耗尽连接池，引发TCP TIME_WAIT暴涨
比换命令更关键的是控制 Hash 规模
靠 HSCAN 救急可以，但长期依赖它说明模型设计有问题。一个 Hash 存几十万字段，本身就是反模式。
- 优先检查是否真需要全量读：很多聚合任务其实只需部分字段，改用
HMGET key field1 field2更轻量 - 按访问模式拆分：比如把
user:1001拆成user:1001:profile、user:1001:settings，天然限宽，也利于独立过期 - 字段生命周期差异大（如头像 URL 和注册时间），直接用多个
stringkey 替代 Hash，省掉元数据开销，实测内存低约 18% - 严禁上线前没做双写过渡就直接 DEL 大 Hash 重建，期间数据会丢失；应先写新结构，等读流量切完再下线旧 key
真正难的不是怎么写 HSCAN 循环，而是怎么让所有调用方同步切换，以及如何在拆分后避免“部分数据查不到”这类静默故障——这些往往发生在监控看不到的地方。
