info命令可一次性准确获取redis内存信息，重点查看used_memory_human（redis自认内存用量）和used_memory_rss_human（系统视角物理内存），二者比值即mem_fragmentation_ratio，超1.5表明碎片严重。
直接用 INFO 命令一次查全，不用拼凑多个命令。 它返回的字段是稳定、权威、实时的，比 redis-cli --stat 或反复调用 CLIENT LIST 更准也更轻量。
怎么快速看内存占用（used_memory_human 和 used_memory_rss_human）
执行 redis-cli -h host -p port -a password INFO memory，重点盯住这两项：
-
used_memory_human：Redis 自己“认为”用了多少内存（jemalloc 分配器视角），比如2.27M—— 这是你数据 + 缓冲区 + Lua 脚本等的总和 -
used_memory_rss_human：操作系统“看到”的 Redis 占用物理内存，比如9.87M——top里看到的 RSS 值就对应这个 - 如果
mem_fragmentation_ratio> 1.5，说明内存碎片严重；接近 1 是理想状态； - 别只看
used_memory_human，它不包含碎片和进程开销；used_memory_rss_human才是真实压在系统上的内存压力
怎么准确数当前连接客户端（connected_clients）
同样在 INFO clients 输出里找这一行：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
connected_clients:1—— 这就是当前活跃 TCP 连接数（不含从节点复制连接） - 搭配看
blocked_clients：值大于 0 表示有客户端卡在BLPOP等阻塞命令上，不是“死连接”，但可能拖慢响应 - 如果
connected_clients持续高于业务预期（比如常年几百却只跑几个定时任务），大概率是客户端没正确 close，得查应用代码里的连接释放逻辑 - 注意：这个值不等于
CLIENT LIST返回的行数 —— 后者包含已断开但尚未被 Redis 清理的残留连接（比如 FIN_WAIT2 状态），而connected_clients是内核 socket 层确认的活跃连接
为什么不能只靠 CLIENT LIST | wc -l 数连接数
这条命令看似直观，但实际会误导：
-
CLIENT LIST返回的是 Redis 维护的客户端元信息快照，包含部分已断开但未清理的条目（尤其网络异常中断后） - 每行输出含大量字段（
addr、fd、idle等），某些旧版 Redis 在高并发下CLIENT LIST本身可能阻塞或超时 -
connected_clients是原子计数器，毫秒级更新，无锁无竞态，INFO clients的开销几乎可忽略 - 真要溯源异常连接，再用
CLIENT LIST配合grep筛idle或flags（比如找带b标志的阻塞连接）
真正容易被忽略的是 used_memory_rss_human 和 connected_clients 这两个值的组合含义：比如内存涨了但 connected_clients 没变，问题大概率在数据结构或 key 泄漏；如果两者同步飙升，优先查客户端是否重复建连、没复用连接池。
