The query cache stores the text of a
SELECT statement together with
the corresponding result that was sent to the client. If an
identical statement is received later, the server retrieves the
results from the query cache rather than parsing and executing
the statement again. The query cache is shared among sessions,
so a result set generated by one client can be sent in response
to the same query issued by another client.
The query cache can be useful in an environment where you have
tables that do not change very often and for which the server
receives many identical queries. This is a typical situation for
many Web servers that generate many dynamic pages based on
database content. For example, when an order form queries a
table to display the lists of all US states or all countries in
the world, those values can be retrieved from the query cache.
Although the values would probably be retrieved from memory in
any case (from the InnoDB buffer pool or
MyISAM key cache), using the query cache
avoids the overhead of processing the query, deciding whether to
use a table scan, and locating the data block for each row.
The query cache always contains current and reliable data. Any insert, update, delete, or other modification to a table causes any relevant entries in the query cache to be flushed.
The query cache does not work in an environment where you have
multiple mysqld servers updating the same
MyISAM tables.
The query cache is used for prepared statements under the conditions described in Section 7.9.3.1, “How the Query Cache Operates”.
Some performance data for the query cache follows. These results were generated by running the MySQL benchmark suite on a Linux Alpha 2×500MHz system with 2GB RAM and a 64MB query cache.
If all the queries you are performing are simple (such as selecting a row from a table with one row), but still differ so that the queries cannot be cached, the overhead for having the query cache active is 13%. This could be regarded as the worst case scenario. In real life, queries tend to be much more complicated, so the overhead normally is significantly lower.
Searches for a single row in a single-row table are 238% faster with the query cache than without it. This can be regarded as close to the minimum speedup to be expected for a query that is cached.
To disable the query cache at server startup, set the
query_cache_size system
variable to 0. By disabling the query cache code, there is no
noticeable overhead.
The query cache offers the potential for substantial performance improvement, but do not assume that it will do so under all circumstances. With some query cache configurations or server workloads, you might actually see a performance decrease:
Be cautious about sizing the query cache excessively large, which increases the overhead required to maintain the cache, possibly beyond the benefit of enabling it. Sizes in tens of megabytes are usually beneficial. Sizes in the hundreds of megabytes might not be.
Server workload has a significant effect on query cache efficiency. A query mix consisting almost entirely of a fixed set of
SELECTstatements is much more likely to benefit from enabling the cache than a mix in which frequentINSERTstatements cause continual invalidation of results in the cache. In some cases, a workaround is to use theSQL_NO_CACHEoption to prevent results from even entering the cache forSELECTstatements that use frequently modified tables. (See Section 7.9.3.2, “Query CacheSELECTOptions”.)
To verify that enabling the query cache is beneficial, test the operation of your MySQL server with the cache enabled and disabled. Then retest periodically because query cache efficiency may change as server workload changes.