Why should the KEYS command be avoided in production?

KEYS pattern scans the entire keyspace to find matching keys, and because it runs on Redis's single command-execution thread, it blocks every other client from being served for however long that full scan takes — on a dataset with millions of keys, that can mean a multi-second (or longer) freeze of the entire instance, affecting every application using it, not just the one that ran the command.

# avoid in production
KEYS user:*

# use instead
SCAN 0 MATCH user:* COUNT 100

SCAN is the safe alternative: it walks the keyspace incrementally, returning a small batch of keys plus a cursor per call, so the cost of a full traversal is spread across many small, non-blocking operations instead of one large blocking one — at the cost of a weaker consistency guarantee (keys added or removed during the scan may or may not be reflected, unlike KEYS's single atomic snapshot view). For production Redis, KEYS is generally reserved for one-off debugging on a non-critical instance, never for application logic or scheduled jobs, precisely because of the blocking behavior that makes it dangerous at any meaningful dataset size.