Predictive caching in a MySQL-backed infrastructure
Warm caches from known next steps — not only from last hits. Group behaviour is predictable even when individuals are not.
Scaling starts with two rules: skip unnecessary queries, and reuse work you already paid for. The fastest query is the one you never issue, or the one whose result (or pages) you already hold.
Near-predictive: warm from the stream
A known trick: read a replica’s relay log, turn upcoming updates into matching SELECTs, and run them so InnoDB already holds the blocks when the SQL thread applies the change. Search engines use similar pre-touch patterns. Tools in the Maatkit / Percona Toolkit lineage made that approach practical. It is not full prediction — it is synchronising cache with known forthcoming writes.
Actual prediction
Some applications can forecast the next queries: for one user, or more often for a cohort. Individuals look random; groups rarely are. Average carelessly and the useful patterns vanish. When the pattern is real:
- Prefetch the queries that will miss next
- Schedule related work off the request path
- Absorb peak load with warmer caches and shorter p99
This lives in application design, not inside mysqld. Capacity planning that only measures yesterday’s hits leaves the next click cold.