Redis里怎么搞模糊查询才靠谱，实操经验分享和技巧总结

说到在Redis里做模糊查询，很多人第一反应就是用KEYS命令，这确实是Redis自带的一个模糊查询方式，比如你想找所有以“user:session:”开头的键，可以执行KEYS user:session:*，但如果你看过任何一篇像样的Redis最佳实践文章，比如Redis官方文档或者像《Redis设计与实现》这类书里提到的，都会第一个跳出来警告你：在生产环境绝对不要用KEYS命令。

为什么呢？因为KEYS命令是阻塞式的，Redis是单线程模型，它一次只能处理一个命令，当你对一个存了几百万个键的Redis实例执行KEYS *时，Redis会卡住，把所有键都扫描一遍再返回给你，这个过程中，其他所有读写请求都得排队等着，跟高速公路堵车一样，整个服务就瘫痪了，所以这招只能在测试环境玩一玩,看看数据情况。

那不用KEYS，靠谱的办法是什么呢？最主流、最推荐的方法是使用SCAN命令，这也是Redis官方（来源：Redis官方文档）给出的替代方案。SCAN命令的好处是非阻塞的，它不会一次性返回所有匹配的键，而是采用游标方式分批返回，你第一次执行SCAN 0 MATCH your_pattern，它会返回一部分结果和一个新的游标值（比如是123），下次你再执行SCAN 123 MATCH your_pattern，它就从刚才停下的地方继续扫描，这样就把一次性的巨大开销，打散成了很多次小的操作,服务器就不会被卡死了。

不过用SCAN的时候有几点实操经验得注意： 第一，SCAN每次返回的数量是不确定的，可能这次返回10个，下次返回50个，它只是保证每次执行都很快。 第二，在你分批SCAN的过程中，如果数据库里的键发生了增加或删除，可能会有一些键被漏掉或者被重复返回，这是允许的，所以它适用于可以接受一定误差的场景，比如统计大概数量、批量清理过期数据等，但不适用于要求绝对精确的实时查询。 第三，MATCH模式匹配是在数据从数据库中取出来之后才进行的，所以即使你用了MATCH user:session:*，它底层可能还是扫描了所有的键，只是最后把不符合模式的过滤掉了，模糊查询的效率和你模式的模糊程度有关，通配符放在开头（比如*:session）通常效率最低。

除了直接查询键名，另一种更“高级”的模糊查询思路是从数据存储设计上入手,Redis的几种数据结构本身也能帮我们实现类似模糊查询的功能。

对于集合（Set）或有序集合（Sorted Set），我们可以利用它们的特性，假设我们有很多用户，用户名是“user:1:info”, “user:2:info”... 同时我们想按城市分类，查询所有北京的用户，我们可以在新增一个用户时，除了设置键值对，还把他加入到名为“city:beijing”的集合里，这样，要查所有北京的用户，直接SMEMBERS city:beijing就行了，速度极快，这根本就不是“模糊”查询了，而是精确的集合查询，这种通过额外空间换时间，预先建立索引的方式，是应对复杂查询的大杀器，很多实战总结（比如一些技术博客像“阿里云开发者社区”里的一些Redis实践文章）都强调这一点。

再比如，有序集合可以按分数排序，如果我们把用户的注册时间戳作为分数，就可以快速查询某一时间段内注册的用户，这也是一种范围的“模糊”查询。

还有一种情况是对Hash结构里的字段值进行模糊查询，Redis本身不支持直接查询Hash中某个字段的值符合某种模式的数据，这时候常见的做法是把需要模糊查询的字段值单独拿出来，作为另一个键的值，用户信息存在user:123这个Hash里，其中有个name字段，如果我们想按名字模糊找用户，可以维护一个字符串键，比如user_names，它的值可以是一个JSON字符串，包含了所有用户名和对应的用户ID，但这样查询时还是得把整个字符串取回来自己在客户端解析，并不高效，更彻底的做法是借助Redis的模块，比如RediSearch，它可以为Redis提供二级索引和全文搜索功能，能像搜索引擎一样对Hash里的文本内容进行复杂的查询，但这引入了额外的依赖和复杂度,需要评估是否必要。

在Redis里搞模糊查询的靠谱技巧：

1. 弃用KEYS，拥抱SCAN：这是铁律,用于需要遍历键名的场景。
2. 设计优于查询：尽量在数据写入时，就通过Set、Sorted Set等数据结构建立好“索引”，把未来的模糊查询需求变成精确的集合操作,这是最高效的方法。
3. 评估需求引入高级工具：如果业务对Hash内部的字段值有复杂的搜索需求,可以考虑使用RediSearch这样的模块。

核心思想就是，Redis本身不是一个关系型数据库，它的强项是快速访问预先设计好的键，模糊查询”的靠谱程度，很大程度上取决于你是否提前为这种查询做好了数据结构的铺垫,而不是临时抱佛脚去扫描。