MySQL 8.0 query cache removal and external invalidation strategies

Architectural Patterns for Manual Cache Invalidation

Since MySQL 8.0 removed the internal query cache to eliminate global mutex contention, the responsibility for result-set caching has shifted to the application layer. To mirror the automatic invalidation of previous versions, developers should implement one of the following architectural patterns using an external store like Redis or Memcached.

1. Cache-Aside (Lazy Loading) with TTL

This is the most common replacement. The application attempts to read from the cache; on a miss, it queries MySQL and populates the cache for subsequent requests. To prevent stale data, a Time-to-Live (TTL) is assigned to every key.

• Best for: Data that can tolerate brief periods of inconsistency.
• Invalidation: Explicitly delete the cache key during the UPDATE or DELETE operation in the application logic.

2. Write-Through / Write-Invalidate

To ensure higher consistency, the application updates the database and the cache within the same logical transaction block. In a Write-Invalidate approach, the application simply deletes the cached entry upon any write to the underlying table, forcing the next read to fetch fresh data from MySQL.

• Best for: High-consistency requirements.
• Invalidation: Immediate deletion of keys associated with the modified table.

3. Cache Tagging (Group Invalidation)

Because a single table update may invalidate dozens of different query result sets, "tagging" is used. Each cached query is associated with a tag (e.g., table:users). When the users table changes, the application invalidates all keys associated with that tag rather than tracking individual query strings.

Mitigating CPU Spikes on Read-Heavy Workloads

Moving the cache outside the engine introduces network latency and the risk of "Cache Stampedes" (where a cache miss for a hot key triggers hundreds of simultaneous DB queries). Use these strategies to protect MySQL CPU utilization:

• Cache Warming: Pre-populate the external cache with known high-traffic, static result sets during deployment or via a scheduled background job.
• Probabilistic Early Recomputation: Refresh the cache entry slightly before the TTL expires to prevent a hard miss.
• Mutex Locking (Promise Collapsing): Ensure that only one application thread is allowed to query the database for a specific missing key, while other concurrent requests wait for that single result to populate the cache.

Verification and Safety

To verify that the legacy query cache is truly inactive in your environment, run:

SHOW VARIABLES LIKE 'query_cache%';

In MySQL 8.0, this should return an empty set. When implementing external invalidation, always wrap cache deletions in a try-catch block to ensure that a failure in the caching layer does not roll back a successful database transaction.

Diagnostic Detail Needed: Are you utilizing a distributed database cluster (e.g., InnoDB Cluster) or a single primary instance? This determines whether you need a distributed cache invalidation event (like Redis Pub/Sub) to synchronize multiple application nodes.