Use MySQL MEMORY as a cache without Redis

Keep the SQL interface while moving transient, non-critical rows into RAM, with clear recovery and durability limits.

MySQL MEMORY Engine Cache

The MySQL MEMORY engine lets you keep the SQL interface while changing the storage behavior underneath. It stores table rows in RAM and is appropriate only for transient, non-critical data such as caches or temporary working sets.

Use this pattern when:

the source of truth is already MySQL, cache and source need the same schema, the same SQL query should work against cache and durable storage, Redis-style data structures are not needed, cache loss is acceptable.

This is a narrow but powerful tradeoff: reduce data-model drift by making cache and database speak the same query language.

Each durable shard can have a matching cache shard. The application can run the same query against cache first, then rerun it against the durable shard on miss.

Why Not Just Tune InnoDB Buffer Pool?

The buffer pool caches pages for a durable InnoDB table. That helps performance, but it still preserves durable database semantics.

The MEMORY engine changes the contract:

Choice Contract --- --- InnoDB + large buffer pool durable table, memory-cached pages MEMORY engine RAM table, data lost on restart

For a true disposable cache, losing rows on restart is a feature, not a bug.

The common pattern is cache-aside:

For writes, choose intentionally:

write-through cache if read-after-write freshness matters, invalidate-on-write if stale cache is risky, TTL/lazy refresh if approximate freshness is fine.

Requirement MEMORY Engine Fit --- --- same SQL query as source table strong fit set/list/sorted-set cache operations weak fit disposable read model strong fit cross-instance shared cache with mature clustering weak fit cache entries larger than RAM budget weak fit

The pattern is most useful when query reuse is more valuable than cache-specific features.