当前位置：首页 > 问答 > 正文

想知道Redis里到底有哪些表名，怎么查才靠谱呢？

盘雅霜
问答
2025-12-28 00:38:52
8

想知道Redis里到底有哪些“表名”，怎么查才靠谱呢？这个问题问得特别好，因为它直接点中了很多刚开始用Redis的朋友们一个最常见的困惑，咱们得把一个大前提说清楚：Redis本身并没有像MySQL或Oracle里那种叫做“表”（Table）的概念。

（来源：Redis官方文档在介绍Keys和Databases时,明确区分了与传统关系型数据库的差异）

在关系型数据库里，你得先创建一张表，定义好每一列叫什么名字、是什么类型，然后才能往里面存数据，表的结构是固定的，非常规整，但Redis是一种键值（Key-Value）数据库，它的玩法完全不同，你可以把Redis想象成一个巨大的、超级快的“键值对”储物柜，每一个你保存的数据，都需要一个唯一的“钥匙”（也就是Key）来标识，当你需要这个数据时，就用这把“钥匙”去打开对应的储物格。

你问“有哪些表名”，在Redis的世界里，这个问题就等价于在问：“我这个Redis里面，到底有哪些不同种类或不同用途的‘钥匙’（Keys）？” 或者更通俗地说，我怎么才能看清我存进去的所有东西的‘标签’？”

接下来我们就聊聊，怎么查才“靠谱”，靠谱的方法需要平衡几个方面：不能影响线上服务的性能，要能看清楚全局,还要保证操作的安全。

最直接但需要慎用的方法：KEYS 命令

一说到查看所有的Key，很多人第一个想到的就是 KEYS 这个命令，它的用法很简单，比如你想看所有的Key,就输入：

KEYS *

或者你想看所有以 “user:” 开头的Key,就输入：

KEYS user:*

（来源：Redis命令参考手册中对KEYS命令的说明）

为什么说这个方法需要“慎用”呢？这正是“靠谱”与否的关键。

Redis是单线程的！这意味着它在某个时刻只能处理一个命令。KEYS * 这个命令会一次性遍历整个数据库中的所有Key，然后全部返回给你，如果你的Redis里存了几百万、几千万甚至更多的Key，这个操作就会像“卡住”了一样，需要很长很长时间才能完成，在这段时间里，Redis没法处理其他的任何命令（比如你的应用正在发起的读取或写入请求），这很可能导致你的线上服务卡顿、超时甚至瘫痪。

（来源：Redis官方文档多次警告，KEYS命令不应用于生产环境,仅推荐在调试时使用）

想知道Redis里到底有哪些表名，怎么查才靠谱呢？

*绝对不要在正在使用的生产环境（就是对外提供服务的正式服务器）上轻易使用 `KEYS `**，如果你只是在本地自己学习测试，数据库里没几个Key，那用一下无妨，但在生产环境,这被视为一个非常危险的操作。

更安全、更推荐的替代方案：SCAN 命令

那有没有既能看到有哪些Key，又不会堵住整个服务的方法呢？答案是有的，SCAN 命令。

（来源：Redis从2.8版本开始引入了SCAN系列命令,用于安全地增量迭代数据库中的Key）

SCAN 命令的工作方式很聪明，它不是一次性把所有Key都捞出来，而是像翻书一样，一页一页地慢慢翻，它每次只返回一小部分Key（比如几十个或几百个），并且给你一个“游标”（Cursor），你拿着这个游标，再次执行SCAN，它就会从刚才停下的地方继续往下翻，这样就把一个庞大的、耗时的操作，拆分成很多个小的、快速的操作，中间随时可以停掉,对服务器的影响微乎其微。

它的基本用法是这样的：

SCAN 0

这里的 0 表示从最开始扫描，执行后，Redis会返回两个东西：一个是下一次扫描要用到的新的游标数字，另一个是本次扫描到的部分Key的列表，然后你再把新的游标数字代入命令继续扫描，直到游标变回 0,就表示全部扫描完毕了。

想知道Redis里到底有哪些表名，怎么查才靠谱呢？

0.0.1:6379> SCAN 0
1) "17"          -- 下次用的新游标是17
2) 1) "key:123"
   2) "user:abc"
   3) "cache:item:456"
127.0.0.1:6379> SCAN 17
1) "0"           -- 游标变回0，表示扫完了
2) 1) "product:xxx"

你也可以像 KEYS 一样加上模式匹配：

SCAN 0 MATCH user:*

使用 SCAN 命令，是生产环境下查看Key列表唯一靠谱的安全方法。

除了看Key，还能看什么？“命名空间”的智慧

虽然Redis没有表，但我们可以通过给Key起名字的方式来“模拟”出类似表的概念，这通常叫做“命名空间”或者“前缀”的设计。

（来源：Redis实践中的最佳模式（Pattern）之一,即使用冒号分隔的键名来组织数据）

user:1001:profile -> 存放ID为1001的用户基本信息
order:20241001:xxx -> 存放订单相关的信息
cache:homepage:data -> 存放首页的缓存数据

你看，通过这种 类型:ID:字段 的命名方式，即使没有真正的表，我们也把数据管理得井井有条，当你用 SCAN user:* 的时候，就相当于是在查询“用户表”里的所有记录。

其他辅助的“靠谱”方法

查看数据库大小： 在使用任何扫描命令前，你可以先用 DBSIZE 命令看一下当前数据库里大概有多少个Key，如果数量巨大，那你就要更加小心，并坚定地使用 SCAN。
监控工具： 很多Redis的可视化管理工具（比如RedisInsight、rdm等）在连接后，它们展示Key列表的功能，底层通常就是使用 SCAN 命令来实现的,既方便又相对安全。
从设计源头解决： 最靠谱的方法其实是“防患于未然”，在设计和开发应用的时候，就维护一个文档，记录下你的应用会创建哪些类型的Key（前缀是什么），这样你根本不需要去数据库里“盲猜”,直接看文档就知道了。