Redis Fuzzy Search Techniques and the Most Dangerous Commands to Avoid

1. Redis Fuzzy Query

1.1 KEYS pattern performs a full‑table scan and blocks the instance; it returns all matching keys at once, which can cause high CPU usage and timeouts when the dataset is large.

Pattern syntax : ? matches a single character (e.g., h?llo matches hello and hallo); * matches any number of characters (e.g., h*llo matches hllo, heello, hello); [ ] matches one character from a set (e.g., h[ae]llo matches hello and hallo).

Pros : simple and returns all matches in one call.

1.2 SCAN cursor [MATCH pattern] [COUNT count] is designed to avoid the blocking issue of KEYS. It iterates with a cursor, returning a small batch each time. SCAN 0 MATCH user:* COUNT 1000 The client loops until the cursor returns 0, collecting the full result set without blocking the server.

Example

# First call, start from cursor 0
127.0.0.1:6379> SCAN 0 MATCH user:* COUNT 100
1) "125"   # next cursor
2) "user:1001"
   "user:1002"
   "user:1005"
# Continue with the new cursor
127.0.0.1:6379> SCAN 125 MATCH user:* COUNT 100
1) "0"   # cursor 0 means iteration finished
2) "user:1008"
   "user:2001"

1.3 Collection‑type scans (SSCAN, HSCAN, ZSCAN) provide field‑level fuzzy matching for Set, Hash, and Sorted Set structures using the same syntax as SCAN.

2. Commands That Can Cause Redis Blocking

Any command with O(n) or higher complexity may block the single‑threaded Redis instance when the data volume is large.

2.1 General Commands

KEYS *

: scans the entire keyspace; with >100k keys it can block all other operations for several seconds. DEL on large keys (e.g., a List with 1M elements) also has O(n) cost and can freeze the server for seconds.

2.2 Hash Commands

HGETALL

, HKEYS, HVALS: return all fields or values; with >100k fields execution time jumps from milliseconds to seconds, blocking other requests.

2.3 List Commands

LRANGE key 0 -1

: returns the entire list; lists longer than 10k elements cause noticeable latency, and >100k elements can block for several seconds.

2.4 Set Commands

SMEMBERS

, SUNION, SINTER, SDIFF: traverse all members; with >100k elements they become blocking.

2.5 Sorted Set Commands

ZRANGE

and ZREVRANGE without limits iterate the whole ZSet; large ZSets (≥150k members) cause 2‑3 seconds of blocking.

3. Mitigation Strategies

Use incremental scans (SCAN, HSCAN, SSCAN, ZSCAN) and process results in small batches (e.g., COUNT 1000).

Split large keys : break a massive Hash into multiple smaller hashes (e.g., user:info:1001:0, user:info:1001:1 each holding ~10k fields); shard large Lists by time or ID (e.g., queue:order:202301, queue:order:202302).

Replace blocking commands with non‑blocking alternatives : use HSCAN instead of HGETALL, ZRANGE with a limit (e.g., top‑N) or ZSCAN for full traversal.

Asynchronous deletion : use UNLINK (Redis 4.0+) to free memory in the background, or delete large Lists incrementally with LTRIM.

Disable high‑risk commands in redis.conf via rename-command (e.g., rename-command KEYS "").

Monitor slow queries : enable slowlog-log-slower-than 10000 to capture commands >10 ms, then analyze and optimize them.

4. Summary

By avoiding full‑scan commands, using cursor‑based iteration, sharding large data structures, and leveraging asynchronous deletion, developers can prevent Redis from becoming a bottleneck and ensure high availability of services that depend on it.