Stale query cache results on MariaDB replica during statement-based replication

The goal is to determine whether a MariaDB replica’s query cache can serve stale data when the master applies statement‑based replication events that modify tables, particularly when those statements involve non‑deterministic functions such as NOW() or UUID().

This situation arises under MariaDB 10.2 or earlier with the query cache enabled (query_cache_type = 1) and a sufficient size, using statement‑based replication format, and may be exacerbated when the underlying storage engine (e.g., MEMORY or ARCHIVE) does not trigger the query cache invalidation hooks.

It remains unclear whether the replica’s cache invalidation mechanism receives the necessary version information from the replication stream, or if any server variable or replication setting can force a cache refresh without disabling the cache entirely.

• Does the replica’s query cache automatically invalidate entries for tables updated via statement‑based replication when the master’s update uses non‑deterministic functions?
• Are there any server variables or replication settings that can enforce cache invalidation on the replica without turning off the query cache?
• If the cache cannot be trusted in this scenario, what is the recommended approach to maintain read‑scale while avoiding stale reads?