生产环境的 Redis 经常达到千万级 Key 。很多桌面 GUI 一旦连上这类实例，就会出现界面卡顿、内存持续上涨，甚至进程崩溃。打开成员较多的 Hash / ZSet 时，如果客户端试图一次性拉取全部数据，窗口同样容易失去响应。
基于这类问题，我重新设计了另一套加载与渲染路径的软件 RedisViewer——一款面向研发调试的本地 Redis 桌面客户端。它的目标是：采用虚拟滚动应对千万级别数据量，并在超大库场景下增加加载确认，避免误操作拖垮客户端。
把「加载」和「渲染」分开处理
不少 Redis GUI 把两件事绑在一起：Key 如何从 Redis 拉取，以及每一行如何绘制到界面上。数据量上来之后，问题会同时放大。
RedisViewer 的处理方式是：
- 按条件加载目标 Key 。 通过 ScanConfig 配置查询条件（默认 pattern 为
*），使用 RedisSCAN完成目标 Key 的完整扫描与加载。研发环境里，这样可以直接拿到完整结果集，减少反复点击扫描更多分页带来的麻烦。 - 大库先确认。 当
DBSIZE≥ 10 万（阈值可配置，对应「 SCAN 免确认」）时，加载前会要求确认，降低误扫生产库的风险。 - 只渲染可见区域。 Key 列表使用虚拟滚动，结果集规模不等于界面节点规模，有助于控制内存并保持滚动流畅。
Hash / Set / ZSet 成员走另一套策略：分页异步加载，避免一次全量返回把界面卡住。集合规模到数万甚至十几万成员时，差异会比较明显。
概括一下：研发场景默认按条件全量加载目标 Key ；库规模较大时先确认；列表始终虚拟渲染。 在千万级实例上兼顾流畅性和内存占用，主要依靠这三点。
Java 场景下的值查看与编辑
Java 服务写入 Redis 的内容经常不是普通字符串：
-
JDK 序列化：直接查看反序列化后的对象结构
-
转义 / 控制字符：可视化查看与编辑，减少对着原始十六进制猜测的成本
-
Jackson / Fastjson 多态 JSON：按结构查看并编辑
当需要核对缓存内容是否与业务对象一致时，仅靠 GET 往往不够。
本地完成常见性能排查
除了 Key 浏览，RedisViewer 也覆盖常见排查入口：
- SlowLog：定位慢命令
- BigKey：内存持续上涨时查找大 Key
- HotKey：短时 MONITOR 采样，识别热点 Key / 高频命令
- MONITOR：短窗口查看实时命令流
- Command stats：观察命令分布，区分业务流量与监控/连接噪声
常见用法是先看 CPU 、内存、命令量、命中率等趋势，再进入 SlowLog / BigKey / HotKey 下钻。数据在本地处理，不会上传到 RedisViewer 服务器。
本地优先，免费，跨平台
连接凭据本地加密保存；可选 WebDAV 仅用于同步连接配置。Redis 的 Key / Value 不会上传。
支持 Windows / macOS / Linux ，免费使用。
下载地址： https://redisviewer.com
欢迎反馈：研发环境里，你更习惯「按条件一次加载完整结果集」，还是「始终分页加载」？你现在用的 GUI ，通常先在 Key 列表、大集合，还是内存占用上出问题？
Select Language