不能直接用hgetall遍历大hash，因其原子性设计需一次性加载全部字段到内存并序列化返回，易引发客户端oom、redis主线程阻塞及高延迟；应改用hscan游标迭代，并注意游标传递、count合理设置、并发分片等最佳实践。
为什么不能直接用 HGETALL 遍历大 Hash？
当一个 Redis Hash 存了几十万甚至上百万用户字段（比如 user:1001 包含 name、email、status 等上百个 field），HGETALL 会一次性把所有键值对加载到内存并返回，极易触发客户端 OOM 或阻塞 Redis 主线程。实测在 50 万 field 的 Hash 上调用 HGETALL，响应延迟常超 2 秒，且伴随明显 CPU 尖峰。
根本问题不在数据量本身，而在于 Redis 单次命令的原子性设计：HGETALL 必须完成全部读取+序列化+网络传输才返回，无法流式分批。
HSCAN 的游标机制和正确分页姿势
HSCAN 是唯一安全的替代方案，但它不是“分页”，而是基于游标（cursor）的增量迭代——每次调用返回一批 field，并附带下一个游标值；当返回游标为 0 时，表示遍历结束。
关键实操点：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须用
cursor字段接收返回的游标值，不能硬编码 offset 或 limit - 每次调用必须传入上一次返回的游标（即使是
"0"启动），否则可能漏数据或重复 -
COUNT参数只是提示，Redis 不保证每次返回 exactly N 条，实际返回数受内部哈希表结构影响（例如 rehash 阶段可能返回更少） - 客户端需自行去重：如果 Hash 在遍历过程中被并发修改（如新增/删除 field），
HSCAN可能重复返回某些 field，也可能跳过部分 field——这是设计使然，非 bug
示例（Python redis-py）：
cursor = b'0'
while cursor != b'0':
cursor, data = r.hscan('user:1001', cursor=cursor, count=1000)
for field, value in data.items():
process(field.decode(), value.decode())
遍历千万级用户 Hash 时的性能陷阱
单个 Hash 存千万用户字段不现实（Redis Hash 内部是 dict + zipmap/skip list 混合结构，field 超 512 且平均长度 >64 字节时内存开销剧增），但若误把「用户 ID → 用户属性」建模成一个巨型 Hash（如 all_users），就会踩坑：
- Hash 的
rehash过程会显著拖慢HSCAN，尤其在写入密集场景下，游标可能长时间卡在某个桶中 - 客户端未设置超时或重试逻辑，遇到网络抖动或 Redis 暂停响应，容易卡死在某次
HSCAN调用 - 盲目增大
COUNT（如设为 10000）反而降低吞吐：单次响应包过大，增加序列化/网络/反序列化开销，实测在千兆内网中COUNT=500综合效率最高 - 未关闭 pipeline 或连接复用，频繁建连导致 TCP TIME_WAIT 暴涨
真正适合全量遍历的存储结构其实是…
如果业务真需要频繁全量扫描用户信息，Hash 本身就是错误选型。应改为：
- 按用户 ID 分片成多个 Hash（如
users:000~users:999），每个控制在 1~5 万 field，再并发HSCAN多个 key——既分散压力，又避免单 key 成瓶颈 - 改用 Sorted Set 存用户 ID（score=注册时间），再用
HMGET批量查属性（前提是属性已拆到独立 Hash 中，如user_profile:1001） - 导出场景优先走 Redis RDB/AOF 解析或
redis-cli --rdb工具，绕过网络协议层
最常被忽略的一点：HSCAN 对空 Hash 或极小 Hash 效率反而不如 HGETALL——因为游标交互有固定开销。别为了“统一写法”强行套用，该用 HGETALL 的时候就用。
