redis-cli --stat仅显示QPS、内存、连接数等聚合指标，无法定位CPU 100%根因；需配合top -p确认Redis进程占用、slowlog get查慢命令、--hotkeys或tcpdump定位热Key。
redis-cli --stat 只能看聚合指标，不能定位 CPU 100% 的根因
redis-cli --stat 输出的是每秒刷新的汇总数据，包括 instantaneous_ops_per_second、used_memory_human、connected_clients、hit_rate 等。它不采样 CPU，也不区分命令类型或 Key 热度。当你看到 CPU 满载时，--stat 可能只显示 “QPS 从 5k 突增到 40k”，但无法告诉你到底是 KEYS * 在扫库，还是某个 HGETALL big_user_profile 卡住了主线程。
它的真正价值是快速过滤：如果 --stat 中 QPS 平稳但 CPU 已满，基本可排除流量洪峰，转向查慢命令或热 Key；如果 QPS 同步飙升，则优先抓命令流。
配合 top -p 实时确认 Redis 进程是否真占满 CPU
别只信 --stat 的数字。先用 pgrep 找出 Redis 主进程 PID，再用 top 精准盯住它：
-
top -p $(pgrep -f "redis-server")—— 确认是 redis-server 本身在耗 CPU，不是 fork 出的子进程（如 RDB rewrite 或 AOF rewrite）在后台干活 - 观察
%CPU列是否持续 ≥95%，同时注意TIME+是否在快速上涨（说明长时间运行） - 如果
top显示 CPU 高但--stat的 QPS 很低，大概率是单个阻塞型命令（如SMEMBERS huge_set）或大 Key 删除（UNLINK未完成）导致
QPS 暴涨时用 monitor 抓原始命令流（仅限低流量环境）
redis-cli --stat 发现 QPS 异常后，立刻开新窗口执行：
-
redis-cli -h—— 抓 3～5 秒，Ctrl+C 中断-p -a monitor - 高频出现的命令 + Key 组合就是线索：比如连续出现
GET product:1001:stock，就该查客户端是不是没做本地缓存 - 注意：
monitor本身走主线程事件循环，CPU 已 100% 时输出会严重滞后甚至卡住，所以它只适合“刚冒头”的异常，不适合稳态满载 - 生产环境慎用，高并发下
monitor会加剧延迟，建议只在复现窗口期或压测中启用
--stat 输出里最该盯住的三个字段
每次看 --stat，重点不是全屏滚动，而是盯死这三项变化节奏：
-
instantaneous_ops_per_second：突增 → 流量型问题；平稳但 CPU 高 → 操作复杂度问题（如大 Key、复杂命令） -
used_memory_human：同步剧烈波动 → 可能有大 Key 写入/删除；缓慢爬升 → 内存泄漏或淘汰策略失效 -
blocked_clients：非零且持续增长 → 有大量客户端卡在BLPOP/BRPOP上，可能消费端堆积或超时设置不合理
集群场景下，--stat 默认只连单个节点，必须手动对每个主节点重复执行；它不反映槽位倾斜或跨节点请求放大，这些得靠 INFO cluster 和客户端日志交叉验证。
