How Redis Boosts MySQL Performance with Smart Caching and Eviction

I am Redis

Hello, I am Redis , brought into the world by a man named Antirez .

My origin is closely linked to the relational database MySQL . Before I existed, MySQL struggled with rapidly growing data and a surge of read/write requests, especially during massive shopping events like "Double 11" and "618".

Most of those requests are reads, many of which are duplicate queries that waste time on disk I/O. Someone thought, "What if we add a cache to the database?" And thus I was born.

Shortly after, I became good friends with MySQL, often appearing together on backend servers. Applications store data fetched from MySQL in me; subsequent requests retrieve the data from me instead of hitting MySQL again.

To facilitate usage, I support several data structures:

String Hash List Set SortedSet Bitmap …

Because I keep the registered data in memory, I avoid slow disk I/O, saving a lot of time compared to MySQL.

With my help, MySQL’s load is significantly reduced, and overall network service performance improves.

Cache Expiration & Eviction

Memory is limited, so I must remove expired entries to free space. I allow applications to set a timeout for each cached item, and I delete the expired content.

The simplest cleanup is periodic deletion; I perform it every 100 ms (10 times per second). To avoid long pauses, I randomly delete a subset of expired keys instead of scanning everything.

When some keys repeatedly escape random deletion, I use a lazy‑deletion approach: if a request finds an expired key, I delete it immediately.

If memory still fills up, I provide eight eviction policies for applications to choose from:

noeviction : return an error, never delete keys allkeys-lru : LRU eviction of any key volatile-lru : LRU eviction of keys with an expiration time allkeys-random : randomly delete any key volatile-random : randomly delete keys with an expiration time volatile-ttl : delete keys with the shortest remaining TTL volatile-lfu : delete least‑frequently used keys with an expiration time allkeys-lfu : delete least‑frequently used keys overall

Cache Penetration & Bloom Filter

When a request queries data that does not exist, MySQL does useless work and I cannot cache the result, leading to repeated hits on MySQL—this is called cache penetration.

To solve it, I use a Bloom filter , which quickly tells whether a piece of data might exist in a huge dataset. It may produce false positives but never false negatives, so non‑existent queries can be blocked before reaching MySQL.

Cache Breakdown & Cache Avalanche

If many keys expire simultaneously and a sudden surge of requests targets those hot keys, the cache misses cause a massive flood of queries to MySQL, overwhelming it. This situation is known as cache breakdown.

When many expired keys are accessed at once, the resulting flood can trigger a cache avalanche, crashing the backend. Mitigations include randomizing expiration times, setting hot data to never expire, and using the eviction policies described earlier.

Easter Egg

During a crash, all cached data was lost, causing a sudden surge of requests to MySQL again. Remembering the cache state before the crash would have prevented the repeat overload.