MySQL operation and maintenance 23-Query Cache (query cache)

1. Introduction to Query Cache

MySQL Query Cache caches the result set and related information of the submitted SQL statement, which helps to speed up the query response. Generally, there is no need to consider the additional overhead brought by Query Cache, unless it is an application with frequent write operations.

2. Query Cache operating principle

1. When MySQL runs a query statement, it will first check whether it hits the cache, if it hits, it will increase the value of the Qcache_hits state variable, and get the result set from the cache area and return it to the client. If the cache is not hit, proceed to the following steps.
2. The parser decomposes the query statement to build a "parse tree" and verifies that the query statement is grammatically correct.
3. The preprocessor checks whether the tables and columns in the "parse tree" exist, whether the column aliases are confused, and checks related permissions.
4. The optimizer optimizes the "parse tree" to generate an execution plan with the lowest execution cost.
5. Execute this plan, storing query results in the cache.
6. Return the result set to the client.

3. The setting and operation of Query Cache

• Query Cache is disabled by default. The way to disable Query Cache is to set query_cache_size to 0.
• Empty cache: The RESET QUERY CACHE command will clear all current caches, but the FLUSH QUERY CACHE command will not clear the cache.
• View cache configuration parameters:mysql>show variables like'%query_cache%';
• View cache status:mysql>show global status like'%Qcache%';

4. Cache miss

4.1, the definition of cache miss (cache miss)

Any query statement that does not obtain data from the cache is called a "cache miss".

4.2. Reasons for cache misses

There are several reasons for cache misses.

• Statements cannot be cached: Some query statements are not cacheable. There are two main types. One is that the statement contains uncertain values, and the other is that the result set is too large to be saved in the cache. The result of these two reasons will increase the value of the Qcache_not_cached variable;
• New query statement: The query statement sent has not been sent before.
• The cache has been released: the result set of the sent query statement was cached before, but due to insufficient memory, MySQL had to clear some of the previous caches to make room for other new cached results.
• Data changes cause cache invalidation: Data changes can also cause cache invalidation. If the cache invalidation is caused by data changes, you can Com_*confirm how many query statements have changed the data by viewing the values ​​of variables, including Com_update, Com_delete, etc.

5. Judgment method of Query Cache efficiency

1. The easiest way to judge whether the Query Cache is effective is the cache hit rate. The formula is Qcache_hits/(Qcache_hits+Com_select). If the cache hit rate is relatively high, then it is effective. Generally, if the hit rate is above 98%, it means that the Query Cache is very effective. In this case, if the Query Cache may cause performance degradation.
2. But even if the cache hit rate is not high, it does not necessarily mean that it is inefficient and must not be enabled. Because sometimes we may focus on improving the access speed of specific queries rather than the overall hit rate.
3. If most of the queries in a system are complex, then using Query Cache will be a good choice.

6. Key points of using Query Cache

• For applications with frequent write operations, it is recommended to disable Query Cache : because as long as one statement changes the table, even if only one piece of data is changed, MySQL will invalidate the entire Query Cache related to this table. At this time, Query Cache not only does not help, but also reduces efficiency due to frequent alternate loading and invalidation operations.
• Standardized development helps improve Query Cache hits: SQL statements are looked up in Query Cache through a hash mapping table, so differences in case, spaces, etc. will lead to different hash results, so developers should have consistent code Specifications to ensure consistent style of SQL statements.
• Query Cache does not cache subqueries.
• Long transactions will reduce the efficiency of Query Cache: Because the modification of the table in the transaction will invalidate the Query Cache related to the table, the result set of the table can not be re-cached until the transaction is committed.
• Query Cache does not need to wait for all the result sets to be generated in the Cache before sending them to the client.
• When Query Cache allocates memory, at least a memory block of query_cache_min_res_unit size must be allocated each time. In fact, the Query Cache required for the result set in the production environment is not very large, and generally 256MB is enough.
• If Qcache_not_cached is small, but there are a large number of cache misses, then there may be many invalid operations, or MySQL does not warm up the data, or there are few repeated queries. Qcache_inserts should be much smaller than Com_select after warming up the data.

7. Summary

1. MySQL's Query Cache (query cache) saves query results to the cache to improve query efficiency. Generally, the overhead of query cache is negligible, but for applications with frequent writes, the overhead of query cache must be considered.
2. Query cache saves the query statement in the cache by hashing the query statement, and compares the hash values ​​of the two statements next time to confirm whether the statement hits. Therefore, capitalization and spaces will affect the cache hit, so if you want to use the query cache, SQL development Be as regulated as possible.
3. The so-called cache miss means that the statement cannot be found in the cache. Generally, new statements, cache release, and cache invalidation will cause cache miss.
4. The efficiency of the query cache can be measured by the cache hit rate. The formula is Qcache_hits/(Qcache_hits+Com_select). If the hit rate is higher than 98%, the query cache is more effective.
5. For applications with frequent write operations, it is recommended to disable Query Cache. Because for the query cache, as long as a record of a table is updated, the query cache of the entire table will be invalidated.