Group items tagged

uses non-deterministic functions such as UUID(), RAND(), CONNECTION_ID() etc it will not be cached.

If table gets modification all queries derived from this table are invalidated at once

if you have high write application such as forums, query cache efficiency might be pretty low due to this.

all queries are removed from cache on table modifications - if there are a lot of queries being cached this might reduce update speed a bit

Qcache_free_memory and Qcache_lowmem_prunes

number of your selects - Com_select and see how many of them are cached. Query Cache efficiency would be Qcache_hits/(Com_select+Qcache_hits).

One portion of query cache overhead is of course inserts so you can see how much of inserted queries are used: Qcache_hits/Qcache_inserts Other portion of overhead comes from modification statements which you can calculate by (Com_insert+Com_delete+Com_update+Com_replace)/Qcache_hits

want to set query cache

means it is much more efficient as query which required processing millions of rows now can be instantly summoned from query cache

It also means query has to be exactly the same and deterministic, so hit rate would generally be less

full page caching

not using query_cache_wlock_invalidate=ON locking table for write would not invalidate query cache so you can get results evenif table is locked and is being prepared to be updated

it can serve responses very fast doing no extra conversion or processing.

but it is still not as fast as specially designed systems such as memcached or local shared memory.

It is not distributed If you have 10 slaves and use query cache on all of them cache content will likely be the same, so you have multiple copies of the same data in cache effectively wasting memory