我会比较各节点 QPS、带宽、CPU、慢日志、命令分布和客户端超时。热 key 往往是某个 key 请求次数极高，可以从代理/客户端埋点、Redis hotkeys 抽样或流量镜像发现；大 key 则通过 MEMORY USAGE、--bigkeys 的低峰抽样和数据结构长度确认。

热 key 的治理取决于读写：热门商品读可以加本地缓存、请求合并，或把只读副本作为分担；热点计数可分桶后汇总。大 Hash/List/Set 会让单命令阻塞和网络包变大，我会按业务维度拆 key、限制长度，删除时用渐进式 UNLINK 或分批操作。

事故中先限流热点入口、关闭大范围读取、把高风险命令下线，必要时迁移或扩容节点。不能直接在线执行全量扫描或同步删除几 GB key，那会让本已抖动的节点更严重。

修复后为单 key QPS、value 大小、集合元素数和慢命令建立预算，问题才不会等到节点倾斜后再发现。