Original Address: https://www.cnblogs.com/leixuesong/p/5388292.html
MySQL caching method for starting and arguments detailed query_cache_size = 32M query_cache_type = 1, the default configuration, MySQL This function is not activated, you may '% query_cache%' by show variables like; will find its variable have_query_cache value is yes, MYSQL beginners can easily think that this parameter to YES on behalf opened the query cache is actually wrong, this parameter indicates the current version of MYSQL support query cache, whether the query cache is actually open to see the value of another parameter: query_cache_size the value of 0 disables the query cache, which is the default configuration is set to 0.
In MYSQL found the following configuration file or the my.cnf my.ini:
the query_cache_size = 0
when MYSQL select query cache for caching query results, and the next time the same query request is received, perform the actual query processing not directly return result, there is such a query cache can improve the speed of query, the query performance optimization, provided that you have a lot of the same or similar queries, with little change data table, otherwise there is no need to use this feature. You can check whether the current value of your current system to meet the load value by Qcache_lowmem_prunes variables. Note: If you query a table is updated more frequently, and rarely have the same query, it is best not to use the query cache.
MYSQL query cache specific configuration:
1. Query_cache_size to the specific size, the specific size is the actual number depends on the query, but is preferably set to a multiple of 1024, the reference value 32M.
2. Add the line: query_cache_type = 1
query_cache_type parameter is used to control the type of cache, not just pay attention to the value set must be set to digital, as well as optional items are described below:
MySQL caching method for starting and Parameter Description
If set to 0, it can be said, simply do your cache no use, equivalent to disabled. But the size of the system in this case query_cache_size set whether you want to assign it, this issue needs to be tested?
If set to 1, all results will be cached, unless you use the select statement SQL_NO_CACHE query cache is disabled.
If set to 2, only you need to specify the cache by SQL_CACHE cached query in the select statement.
OK, after part of the configuration file as follows:
query_cache_size = 128M
query_cache_type = 1
Save the file, restart MYSQL service, and then verify that really opens by the query:
MySQL> Show the Variables like '% query_cache%';
+ --- + ---- + -------
| variable_name | Value |
+ ---------- + ---- +
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 134217728 |
| query_cache_type | ON |
| Query_cache_wlock_invalidate | OFF |
+ ---------- + ---- +
6 rows in the SET (0.00 sec)
mainly to see the same value query_cache_size and query_cache_type whether the set with us: the
value query_cache_size here is 134217728 we set up a 128M, actually it is the same, just different units can be converted under their own: 134217728 * 1024 * 1024 = 128. query_cache_type set to 1, the display is ON, the already said.
In short, to see the top of the display represents the settings are correct, but if the query can be cached in the actual query, you also need the manual test, we can show status like '% Qcache%' ; statement to test, and now we have opened a query cache function before executing the query, we look at the value of the relevant parameters:
MySQL> Show Status like '% Qcache%';
+ --------- + ---- +
| variable_name | value |
+ - + ---- + --------
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 134 208 800 |
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 0 |
| Qcache_total_blocks | 1 |
+ --------- + ---- +
8 rows in the SET (0.00 sec)
role here interpreted this way several parameters:
Qcache_free_blocks: indicates that the query cache there are currently a number of the remaining blocks, if the value displayed is large, then the query cache memory fragmentation too much, perhaps finishing at a certain time.
Qcache_free_memory: query cache memory size, this parameter can clearly know the current system query memory is enough, is much, or not enough, DBA can make adjustments according to the actual situation.
Qcache_hits: indicates how many times a cache hit. We can verify our main query cache effect by this value. The higher the number, the more ideal buffer effect.
Qcache_inserts: indicates how many times a miss and then insert, which means new to SQL request was not found in the cache and had to perform query processing, query processing the results after executing insert into the query cache. The number of such cases, the more the number, the application to indicate query cache is relatively small, the effect is not ideal. Of course, the system has just started, the query cache is empty, this is normal.
Qcache_lowmem_prunes: This parameter records the number of queries because of insufficient memory be removed out of the query cache. By this value, the user can appropriately adjust the cache size.
Qcache_not_cached: represents the number of queries because query_cache_type setting without being cached.
Qcache_queries_in_cache: the number of queries the current buffer cache.
Qcache_total_blocks: the current number of block cache.
Below we test under:
For example, execute the following query
MySQL> the SELECT * from the User the WHERE the above mentioned id = 2;
+ - + --- +
| the above mentioned id | name |
+ - + --- +
| 2 | test2 |
+ - + --- +
1 row in set (0.02 sec)
is then performed show status like '% Qcache%' , see what changes:
MySQL> Show Status like '%% Qcache';
+ --------- + --- - +
| variable_name | Value |
+ --------- + ---- +
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 134 207 264 |
| Qcache_hits | 0 |
| Qcache_inserts | 1 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 3 |
| Qcache_queries_in_cache | 1 |
| Qcache_total_blocks | 4 |
+ --------- + ---- +
8 rows in the SET (0.00 sec)
Contrast parameter values front, we found Qcache_inserts changed. Qcache_hits not changed, below us in the same query
select * from user where id = 2 , in accordance with previous theoretical analysis: Qcache_hits should be equal to 1, while Qcache_inserts value should be the same (value changes in other parameters temporarily not concern readers to test), perform again:
Show Status like '% Qcache%', see what changes:
MySQL> Show Status like '% Qcache%';
+ --------- + ---- +
| variable_name | Value |
+ --------- + ---- +
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 134 207 264 |
| Qcache_hits | 1 |
| Qcache_inserts | 1 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 4 |
| Qcache_queries_in_cache | 1 |
| Qcache_total_blocks | 4 |
+ --------- + ---- +
8 rows in the SET (0.00 sec)
the OK, really exactly the same analysis with us.