1. Redis模糊查询实战指南

在数据处理领域，快速检索特定模式的数据是常见需求。Redis作为高性能键值数据库，虽然主打简单键值存储，但通过合理设计也能实现灵活的模糊查询功能。本文将深入解析五种主流实现方案，包含完整命令示例和性能对比。

1.1 为什么需要模糊查询？

传统关系型数据库通过LIKE语句实现模糊匹配，但Redis作为NoSQL数据库，原生只支持精确键查询。实际业务中常遇到这些场景：

• 用户系统：按姓名前缀搜索（"张*"）
• 商品系统：按分类后缀匹配（"*手机"）
• 日志系统：包含特定关键词（"error"）

关键提示：Redis所有模糊查询本质上都是客户端实现的模式匹配，服务端仅提供键遍历能力

2. KEYS命令方案及风险控制

2.1 基础使用模式

# 查询user:开头的所有键 KEYS user:* # 查询以123结尾的键 KEYS *123 # 查询包含order的键 KEYS *order*

2.2 致命缺陷与解决方案

KEYS命令会阻塞Redis单线程，导致服务不可用。生产环境必须遵循：

1. 只在从节点执行
2. 使用SCAN替代方案
3. 限制匹配模式复杂度

# 安全扫描示例 SCAN 0 MATCH user:* COUNT 100

3. 有序集合+Lex方案详解

3.1 数据结构设计

ZADD users 0 "user:1001:张三" ZADD users 0 "user:1002:李四"

3.2 范围查询实战

# 查询张姓用户 ZRANGEBYLEX users "[user:" "(user:\xff"

3.3 性能对比测试

4. Lua脚本优化方案

4.1 脚本示例

local result = {} local cursor = "0" repeat local reply = redis.call("SCAN", cursor, "MATCH", ARGV[1]) cursor = reply[1] for _,key in ipairs(reply[2]) do table.insert(result, key) end until cursor == "0" return result

4.2 执行方式

EVAL "脚本内容" 0 "user:*"

5. 生产环境最佳实践

5.1 索引设计原则

1. 热数据单独存储
2. 使用Hash存储元数据
3. 建立反向索引

5.2 性能优化技巧

• 控制SCAN的COUNT参数（建议500-1000）
• 对大结果集分页处理
• 使用管道批量操作

6. 常见问题排查

6.1 内存溢出处理

当模糊查询返回大量键时：

# 监控内存 INFO memory # 限制返回数量 SCAN 0 MATCH * COUNT 100

6.2 特殊字符转义

处理包含*?[]的键名时：

# 转义方括号 SCAN 0 MATCH *\[test\]*

7. 扩展方案对比

7.1 RediSearch模块

FT.CREATE idx ON HASH PREFIX 1 user: SCHEMA name TEXT FT.SEARCH idx "张*"

7.2 布隆过滤器方案

BF.ADD users "张三" BF.EXISTS users "张三"

实际项目中，我们最终采用ZSET+SCAN组合方案，在百万级用户系统中实现平均8ms的查询响应。关键是要根据数据规模、查询频率和实时性要求选择合适方案。