HGETALL在百万field下不可用，因其必须一次性加载全部field-value至内存并序列化返回，无法分批、中断或限流，导致主线程阻塞数秒、请求排队、超时及客户端OOM；HSCAN通过游标分批迭代，避免内存暴涨和CPU尖峰，是唯一安全可行方案。
HSCAN 是唯一安全可行的方案，HGETALL 在百万级 field 场景下必然卡死主线程、触发超时甚至客户端 OOM。
为什么 HGETALL 在百万 field 下不可用
HGETALL 不是慢，是设计上就拒绝分批：它必须一次性把全部 field-value 加载进内存、序列化成一个大数组、再整包返回。哪怕每个 value 只有 10 字节，100 万 field 就要分配约 10MB 内存+序列化开销，Redis 主线程会被独占数秒——期间所有请求排队阻塞，慢日志里会密集出现 HGETALL 超时记录。
- Hash 编码已从 ziplist 升级为 hashtable（字段数 > 512 或任意 value > 64 字节），内存指针开销翻倍，
HGETALL序列化压力更大 - 客户端收到完整响应后还要二次解析，容易在应用层触发 GC 尖峰或内存溢出
- 没有游标、无法中断、不能限流，等于把“全量搬运”任务强塞给单线程
HSCAN 游标循环的正确写法（Python / Java）
关键不是调一次 hscan，而是用游标驱动完整迭代闭环。漏掉游标续传或忽略返回值类型，会导致漏数据或无限循环。
- 第一次必须传
cursor=0（字节串，如b'0'），后续每次必须用上一轮返回的cursor值，硬编码0或忽略会导致重头扫描 - 返回结构是
[cursor, {field: value, ...}]，cursor是字节串，比较时要用cursor == b'0'，不是cursor == '0'或cursor == 0 - Java Jedis 中，
jedis.hscan(key, cursor, params)只返回单次结果，需手动循环；建议封装成带重试和中断保护的工具方法
Python 示例：
cursor = b'0'
while cursor != b'0':
cursor, data = r.hscan('user:1001', cursor=cursor, count=300)
for field, value in data.items():
process(field.decode(), value.decode())
COUNT 参数设多少才合理
COUNT 是提示值，不是硬上限，实际返回数量可能少于该值（尤其 Hash 正在 rehash 或字段稀疏时）。设太小导致请求爆炸，太大则单次响应包过大、网络延迟升高、客户端解析压力陡增。
- 实测在千兆内网中，
COUNT=300～500综合效率最高；万兆环境可试探到 800，但不建议超过 1000 - 不要设
COUNT=10000试图“一步到位”，这会让单次响应包轻易突破 1MB，触发 Redisclient-output-buffer-limit限制，直接断连 - 若业务允许弱一致性，可在循环中加入
time.sleep(0.01)控制吞吐节奏，避免打满 Redis 网络带宽
并发修改下 HSCAN 的重复与遗漏问题
Hash 在遍历过程中被其他客户端 HSET 或 HDEL，HSCAN 可能重复返回某些 field，也可能跳过部分 field——这不是 bug，是 Redis 渐进式遍历的底层机制决定的（基于哈希表桶遍历 + rehash 过程中的双表切换）。
- 强一致性场景（如导出快照做审计）必须由业务层加校验：例如用
HLEN对比总字段数，或对 field 做 MD5 聚合校验 - 清理类操作（如批量
HDEL失效字段）建议配合UNLINK而非DEL，让删除异步化，避免阻塞遍历过程 - 永远不要假设
HSCAN返回顺序固定——它不保证字段顺序，也不保证两次遍历结果一致
真正难的不是写对第一次 hscan，而是在高并发、长周期、多实例环境下维持游标状态不丢失、不越界、不漏批。游标本质是哈希表内部位置标记，一旦连接中断或应用重启，就得从头开始，这点必须纳入重试和断点设计。
