用Redis怎么搞模糊查表名这事儿，聊聊那些技术细节和思路

首先得明确一点，Redis本身的设计是键值存储，它的“键”（也就是你所说的“表名”，更准确地说是我们存数据用的那个key）是二进制安全的字符串，但它没有像关系型数据库（比如MySQL）那样内置的、直接的“模糊查询”功能，你不能在Redis里写一个像SHOW TABLES LIKE '%user%'这样的命令，我们要做的其实是在Redis的能力范围内，自己设计一套模式来实现类似“按模式找key”的效果。

这事儿的核心思路，说白了就是用空间换时间，并利用Redis提供的一些基础命令来拼凑出我们想要的功能,下面我详细聊聊几种常见的搞法和技术细节。

第一种最直接的办法：KEYS 命令。

这是最广为人知但也最不推荐在生产环境用的方法，Redis确实提供了KEYS pattern这个命令，你可以用、这样的通配符来匹配键名，你想找所有以user:profile:开头的键，可以执行KEYS user:profile:*。

• 技术细节：KEYS命令的问题是，它会遍历整个数据库的所有键，如果你的Redis里存了几百万甚至上亿个键，这个操作可能会阻塞Redis服务器好几秒甚至更久，在这段时间里，Redis无法处理其他任何请求，对线上服务来说这是灾难性的，几乎所有的Redis运维规范都会告诉你：绝对不要在生产环境使用KEYS命令，它只适合用在调试环境,或者你百分百确定数据库里键的数量非常少的情况。

第二种更稳妥的办法：SCAN 命令。

既然KEYS会阻塞，Redis从2.8版本开始提供了SCAN命令族（包括SCAN本身、SSCAN for sets、HSCAN for hashes等）来解决这个问题。SCAN是一种增量式的、迭代式的遍历命令。

• 思路和细节：
  1. 不阻塞：SCAN不会一次性返回所有匹配的键，而是每次只返回一小部分（比如几十个），并给你一个游标（cursor），你下次带着这个游标再发SCAN命令，它就从上次停下的地方继续遍历，这样就把一个庞大的、耗时的操作拆分成很多个微小、快速的操作，中间可以穿插处理其他客户端的请求,避免了长时间阻塞。
  2. 用法：命令形式是SCAN cursor [MATCH pattern] [COUNT count]，你可以用MATCH来指定模糊匹配的模式（和KEYS的模式一样），用COUNT来暗示每次返回的大致数量（注意这只是个提示，Redis不一定完全遵守）。
  3. 缺点：它不是强一致性的，在你这几次SCAN迭代的过程中，可能会有新的键被添加进来，或者旧的键被删除，所以最终返回的结果集可能不能完全精确反映遍历开始那一刻的数据库状态，但对于模糊查找表名这种场景,通常是可以接受的。
  4. 怎么用：你需要在你的应用程序里写一个循环，不断地调用SCAN，直到返回的游标为0，表示遍历完成，然后把每次返回的结果累加起来,就得到了所有匹配的键。

第三种是“设计上”的办法：主动维护索引。

上面两种方法都是在“找”键，属于事后查询，更高级的思路是“治未病”，在写入数据的时候，就提前把“索引”建好,这才是发挥Redis高性能优势的正道。

• 思路：你不是想知道有哪些“表名”吗？那我们专门用一个或一组Redis的集合（Set）或有序集合（Sorted Set）来存放所有这些“表名”的索引。
• 技术细节：
  1. 写入时维护：每当你的程序创建一个新的“表”（比如设置了一个键为user:profile:1001），在设置完这个键值对之后，同时要执行一个SADD index:user:profiles user:profile:1001，这里的index:user:profiles就是一个我们专门用来存储所有用户profile键的集合。
  2. 查询时：当你想模糊查找时，问题就简化了，如果你要找的就是所有user:profile:*的键，直接SMEMBERS index:user:profiles命令把这个集合的所有成员取出来就行了，这个操作是O(1)时间复杂度,速度极快。
  3. 处理更复杂的模糊：如果模糊查询的条件更复杂，比如你想找包含2024的键，你可以维护一个更通用的索引，把你所有的“表名”同时放入一个集合，然后用SINTER（求交集）命令来实现复杂查询，或者，如果你需要按前缀以外的模式搜索，可以考虑将键名分词，然后把每个词作为集合的成员，原始键名作为集合名，利用集合操作来查询，但这会变得更复杂,需要仔细设计。
  4. 优缺点：优点是查询速度爆炸快，是O(1)或O(logN)的，缺点也很明显：增加了写入的复杂度和存储成本，你每写一个数据，都要额外写一次索引，还要保证这两个写操作的事务性（可以用Redis事务MULTI/EXEC或Lua脚本来保证原子性，避免脏数据）,索引本身也要占用内存。

• 如果你只是偶尔在维护阶段手动查一下，键的数量又不多，用KEYS命令最简单,但心里要清楚风险。
• 如果你的应用需要经常性地、在线上服务中进行模糊查找，SCAN命令是首选，它平衡了功能和性能,实现起来也不复杂。
• 如果你的应用对查询性能要求极高，表名”的模式相对固定（比如就是清晰的前缀），那么花费额外的代价在写入时维护一个索引集合，是长远来看最好的方案，这体现了数据库设计中一个常见的权衡：用写的代价来换取读的极致速度。

搞模糊查表名这事儿，没有唯一的正确答案，得看你的具体场景：是偶尔查还是频繁查？数据量有多大？对查询速度的要求有多高？对服务稳定性的要求又有多严格？想清楚这些,再选择最适合你的那套打法。