监控里 HGETALL 单次耗时 3.2 秒，实例 CPU 直接打满，同实例其他接口跟着变慢。日志里能对上时间点，这种反而好排。
整个商品维度塞进一个 hash，四十万个字段一次全量拉取，序列化和网络传输都压在单线程上，一次操作就把实例顶住。这一点先确认清楚，后面就不用反复试。
HSCAN sku:1001 0 COUNT 500 HMGET sku:1001 f1 f2 f3 SLOWLOG GET 10 redis-cli --bigkeys
「Redis 大 key 拆分」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。先做最小复现，能稳定跑出来的问题，排查成本会低一个数量级。
别只看报错的最后一行，往上看几行，真正的起因通常在上面。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。
把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
处理上按这个顺序：按字段前缀拆成若干小 hash 键名带分片号；只取需要的字段 用 HMGET 代替 HGETALL；全量导出的任务挪到从库 用 HSCAN 分批读。
结果对不对很好判断，拆完单次操作回到 10 毫秒内，slowlog 里不再出现这条命令。