HGETALL变慢的根本原因是其一次性加载全量Hash数据至内存并传输，导致网络、解析和内存压力剧增；应改用HSCAN分批读取，并按业务维度或哈希取模拆分大Hash，配合双写过渡与客户端拦截兜底。
Redis集合数据暴增后HGETALL变慢的根本原因
不是Redis本身扛不住，而是HGETALL会一次性把整个Hash所有字段全读进内存再发给客户端——集合越大，网络传输越久、客户端解析越卡、服务端临时内存占用越高。尤其当单个Hash存了上万对field:value，哪怕总数据才几MB，HGETALL也常触发毫秒级延迟甚至超时。
用HSCAN替代HGETALL分批读取
HSCAN是唯一靠谱的平滑迁移方案，它不阻塞、不爆内存、支持游标续扫。但要注意默认每次只返回10条，实际得调大COUNT参数才能兼顾效率和可控性：
- 生产环境建议设
COUNT为100~500，太小导致请求次数爆炸，太大可能单次响应超20ms - 必须自己维护游标（
cursor），第一次传0，后续用上一轮返回的新cursor，直到返回0为止 - 注意：
HSCAN不保证顺序，也不保证一次扫完所有数据（有概率漏，但概率极低；若强一致性要求高，需加业务层去重或版本号校验）
拆分大Hash的两种实操路径
不能硬扛，必须从源头控制单个Hash规模。拆分逻辑要和业务查询模式对齐，否则徒增复杂度：
- 按业务维度切分：比如用户订单Hash原为
order:uid:123，存全部订单，改为order:uid:123:202401、order:uid:123:202402，按月分片 - 按ID哈希取模：对
field名做hash(key) % N，写入hash:N，查时同样计算路由——适合无明显时间/分类维度的场景 - 严禁直接用
DEL删大Hash再重建，期间会丢数据；应双写过渡，等新读路径稳定后再下线旧key
限制单次HGETALL返回量的兜底手段
上线前没来得及改代码？可用Redis配置+客户端拦截双保险：
- 在
redis.conf里加maxmemory-policy noeviction防止误删，但这不解决HGETALL本身问题 - 真正有效的是客户端层拦截：比如Java用Lettuce，在命令执行前判断key是否命中黑名单（如正则
^order:uid:），命中则抛异常或自动转为HSCAN - Redis 7.0+支持ACL规则限制命令参数，但
HGETALL不带参数，无法按大小拦截——所以依赖服务端限制不现实，必须前端控
最麻烦的不是怎么拆，而是拆完如何让所有调用方同步切换。老接口还在用HGETALL，新代码走HSCAN，中间没做兼容桥接的话，很容易出现“部分数据查不到”这种静默故障。
