#cli

redis-cli --scan --pattern 'KEY_PREFIX*' | xargs -r -n 500 redis-cli UNLINK

--scan walks the keys in chunks.

UNLINK — it frees the memory on a separate thread, no blocking. -n 500 so you don’t spawn a process per key, -r skips the call when nothing matches.

Check what you’re about to nuke first:

redis-cli --scan --pattern 'KEY_PREFIX*' | head

--scan only walks on your current node (check –cluster call for cluster)

Biggest keys

redis-cli --bigkeys

Walks the whole database with SCAN and shows the biggest key of each type.

Mind the units: for strings it counts bytes, for collections the number of elements. A list with a million short entries will look “bigger” here than a single 10 MB string.

What it actually weighs

redis-cli --memkeys

Same walk, but measured with MEMORY USAGE — real bytes. Slower, but it doesn’t lie. Redis 6 and up.

A single key:

redis-cli MEMORY USAGE mykey

Both walks cover the entire keyspace. On a large database add -i 0.1 so they pause between batches instead of hammering the server.

Command stats

INFO commandstats

How many times each command ran and how long it took on average (usec_per_call). Usually this is where it turns out Redis isn’t slow — somebody is just hammering KEYS in a loop.

Reset the counters before measuring:

CONFIG RESETSTAT

Before merging your branch (the one you are working on alone), do your own squash:

git reset HEAD~x --soft

(soft keeps the files in the index, so you do not need to select them)

Then rebase the branch onto main and push:

git rebase main
git push --force-with-lease

This is a better option than squash on merge, because if you want to return to the branch later, you still have consistency with the remote.

It gives you great order in the repository and history, but you have fewer commits and changed lines, which can be bad if you end up with a manager who does micromanagement and compares productivity based on the repo