Paste a article about MySQL. Mysqls Query Cache for e-text

Cache|mysql A Typical Scenario
Boss:our New website is crawling! How can it be, we have four State-of-the-art Web servers-what ' s problem?
You:well, the Web servers are fine-it ' s the database server that ' s struggling.
Boss:what? You are told me this MySQL thing is fast, that we didn ' t need Oracle, and now you say it can ' t cope! How can I be?
You:well, the Web servers are behaving so. They ' re pushing through lots of queries, and the database can ' t manag E to process all of them in the same time. It ' s only one database, and lots of Web servers ...
Boss:it ' s too late to-buy Oracle Now-what are we going to do!?
Big Boss to Boss (in the Boss's mind): This project has been a disaster from the Beginning-now your want me to delay it wh Ile We install a new database, and spend a whole lot more! Do we ' re made of money!? I ' m calling in someone who knows what they ' re doing-you ' re history buddy.
Colleague (about to take your job): Wait, I am I can solve the problem!

So, what does your colleague know ' don ' t? How can I save the "day" and let the "Boss get All" credit? Our scenario are too imprecise to generalize, and there are many. Possible solutions. Can read about optimizing queries and indexes, optimizing by improving the hardware, and tweaking the MySQL variables, Using the slow query log, and of course, there are other methods such as replication. However, MySQL 4 provides one feature that can prove very query cache. In a situation where the "database has to repeatedly run" same queries on the same data set, returning the same results The MySQL can cache the result set, avoiding the overhead of running through the data over and over. Usually, you would want to implement some sort of caching in the Web server, but there are times when this isn't possible , and then it is the ' query cache you ' to ' for help.

Setting up the query cache
To make sure MySQL uses the query cache, there are a few variables for need to set in the configuration file (usually my.c NF or My.ini). The Query_cache_type. There are three possible settings:0 (for off, does not use), 1 (for on, cache queries) and 2 (on demand, discussed more Bel ow). To ensure it's always on, place:

Query-cache-type = 1
In the configuration file. If you started the server has only made this change, you would the following cache variables set:

Mysql> show VARIABLES like '%query_cache% ';
+-------------------+---------+
| variable_name | Value |
+-------------------+---------+
| Have_query_cache | YES |
| Query_cache_limit | 1048576 |
| Query_cache_size | 0 |
| Query_cache_type | On |
+-------------------+---------+
4 rows in Set (0.06 sec)

Note This is are results from MySQL 4.0.x-you ' ll-more in versions 4.1.x and beyond. The Query_cache_type is set to on or off as appropriate. However, there is one more to set, and this is the query_cache_size. If set to 0 (the default), the cache would be disabled. This is variable determines the memory, in bytes, and used for the query cache. For our purposes, we'll set it to MB:

Query-cache-size = 20M
The amount is shown in bytes:

Mysql> show VARIABLES like '%query_cache% ';
+-------------------+----------+
| variable_name | Value |
+-------------------+----------+
| Have_query_cache | YES |
| Query_cache_limit | 1048576 |
| Query_cache_size | 20971520 |
| Query_cache_type | On |
+-------------------+----------+
4 rows in Set (0.06 sec)

The Query cache in action (almost)
For this tutorial, I used a dump to Wikipedia, the Open content encyclopedia (you can find the dumps here. I am using a fairly slow machine, with nothing else happening on it, to minimize interference in the results. Let's run the same query twice, and you are so much improvement we have the second time:

SELECT * FROM cur;
...
14144 rows in Set (2.96 sec)
Now we run the same query again:
SELECT * FROM cur; 14144 rows in Set (3.02 sec)

Now we run the same query again:

SELECT * FROM cur; 14144 rows in Set (3.02 sec)

What is happening? We would expect the second query to take noticeably less time. Let's examine some of the status variables to get a better picture.

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 0 |
| Qcache_inserts | 2 |
| Qcache_hits | 0 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 2 |
| Qcache_free_memory | 20962720 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 1 |
+-------------------------+----------+
8 rows in Set (0.00 sec)

The two queries we ran are both recorded (by Qcache_inserts), but neither to them have been. (You'll get different results if queries have been running.) The problem is this result set was too big. I used the Wikipedia Esperanto dump (4MB compressed-the 中文版 dump is 135MB, and even though my Chinese is better than My Esperanto, bandwidth are expensive in South africa!), but it is immaterial, as even that's more than the query cache C An handle by default. There are two limits in play here-the limit to each individual query are determined by the value of Query_cache_limit, W Hich is 1MB by default. Moreover, the limit of the cache in total are determined by query_cache_size, which we have seen already. The former limit applies here. If a result set is greater than 1M, it isn't cached.

The Query cache in action (really)
Let ' s try a smaller query:

SELECT cur_is_new from cur WHERE cur_user_text > ' Y '
...
2336 rows in Set (0.38 sec)

Let ' s-if this one is cached:

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 1 |
| Qcache_inserts | 3 |
| Qcache_hits | 0 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 2 |
| Qcache_free_memory | 20947592 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 4 |
+-------------------------+----------+
8 rows in Set (0.00 sec)

There is now query in the cache. If it took 0.38 seconds to run the "I", let ' s if we notice a improvement the second time:

SELECT cur_is_new from cur WHERE cur_user_text > ' Y '
...
2336 rows in Set (0.11 sec)

Much better! And, looking at the status again:

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 1 |
| Qcache_inserts | 3 |
| Qcache_hits | 1 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 2 |
| Qcache_free_memory | 20947592 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 4 |
+-------------------------+----------+
8 rows in Set (0.06 sec)

The cache has been hit once. The status variables above should is fairly self-explanatory. Available memory for the cache has gone from 20962720 to 20947592. The most useful variable for future tuning is qcache_lowmem_prunes. Each time a cached query are removed from the query cache (because MySQL needs to make spaces for another), this value would Be incremented. If it increases quickly, and you still have memory to spare, you can up the query_cache_size, while if it never increases, You can reduce the cache size.

Let's run the query again, with a slight difference, as follows:

SELECT cur_is_new from cur where cur_user_text > ' Y '
...
2336 rows in Set (0.33 sec)

That took longer than we would have expected. Let's look in the status variables to what ' s up:

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 2 |
| Qcache_inserts | 4 |
| Qcache_hits | 1 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 2 |
| Qcache_free_memory | 20932976 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 6 |
+-------------------------+----------+

The query has not made to the cache-in fact, MySQL has inserted query in the another The problem is this is this MySQL ' s query cache is case-sensitive (in fact it is byte sensitive). The query must is identical in every way-no extra spaces, no changes in case. Therefore, the above query is treated as a different query. This fact alone should is enough for your to adopt a certain convention, and ensure all application developers It. I Use the caps for the MySQL keywords, and lower case for table and field names.

Clearing the Query cache
The cache cannot stay in memory indefinitely. Luckily, MySQL is clever enough to clear it if you are changes to the tables used in a cache query. If We insert a new record to the Cur table, MySQL'll clear the affected queries (and only the affected queries) from the Cache

Mysql> INSERT into cur (cur_user_text)
VALUES (' xxx ');
Query OK, 1 row affected (0.06 sec)

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 0 |
| Qcache_inserts | 4 |
| Qcache_hits | 1 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 2 |
| Qcache_free_memory | 20962720 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 1 |
+-------------------------+----------+

Any inserts, UPDATE, DELETE, TRUNCATE, ALTER, DROP TABLE or drop DATABASE potentially remove queries from the cache. Can manually clear the query cache with RESET query cache.

Query Cache On Demand
Earlier we saw there were three values for the Query_cache_type. On, off and on demand. The latter option means that queries to be cached if Sql_cache was specified in the query. Let ' s restart the server, with

Query-cache-type = 2
In the configuration. Restarting the server flushes all the status variables. We run our previous query again:

SELECT cur_is_new from cur WHERE cur_user_text > ' Y '
...
2336 rows in Set (0.27 sec)

It is back to a longer time again, as the cache has been flushed.

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 0 |
| Qcache_inserts | 0 |
| Qcache_hits | 0 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 1 |
| Qcache_free_memory | 20962720 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 1 |
+-------------------------+----------+

Nothing has been recorded. To store a query on the cache, we need to run the query with Sql_cache, as follows:

SELECT Sql_cache cur_is_new from cur WHERE cur_user_text > ' Y '
...
2336 rows in Set (0.33 sec)

This time it has been stored the cache.

Mysql> show STATUS like '%qcache% ';
+-------------------------+----------+
| variable_name | Value |
+-------------------------+----------+
| Qcache_queries_in_cache | 1 |
| Qcache_inserts | 1 |
| Qcache_hits | 0 |
| Qcache_lowmem_prunes | 0 |
| qcache_not_cached | 1 |
| Qcache_free_memory | 20947592 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 4 |
+-------------------------+----------+

If the cache type is set to 1, there may are times and you know the query for you are running won't be repeated, or more in frequently. In this situations, you can ask the MySQL no to store the results in the cache, even if they adhere to the size limitations, With the Sql_no_cache clause in the SELECT statement.

Block allocation and the Query cache
MySQL allocates results into the cache in blocks, during retrieval. This is allocation comes at a overhead (the quicker time to run the above query when it is not being cached). You should don't enable the query cache unless you can make good use of it. The number of free blocks (qcache_free_blocks) can is a indication of fragmentation-a high Tal number of the blocks means is being wasted. In MySQL 4.1, there is another cache-related variable:query_cache_min_res_unit. This is allows to set a minimum block size. The default is 4KB. If most of your query results are small, and you are here fragmentation, you should decrease this. The converse applies if most of your result sets are. To defragment a query cache, your can use FLUSH query cache (FLUSH TABLES has the same on the cache).

There are situations when a query cannot is cached, all of which make perfect sense, such as when returning the current Ti Me, a random number, user variables, or when dumping to a file. Any queries making use of the following functions, or of the following types, won't is cached:

user-defined functions
BENCHMARK
connection_id
Curdate
Current_date
Current_time
Current_timestamp
Curtime
DATABASE
ENCRYPT (with one parameter)
Found_rows
Get_lock
last_insert_id
Load_file
Master_pos_wait
Now
RAND
Release_lock
Sysdate
Unix_timestamp (without parameters)
USER
Query contains user variables
Query references the MySQL system database
Query of the form SELECT ... In SHARE MODE
Query of the form SELECT ... Into outfile ...
Query of the form SELECT ... Into DumpFile ...
Query of the form SELECT * from Autoincrement_field is NULL
Queries inside transactions (in MySQL 4.0.x)
Wisely used, the query cache can make a substantial difference to struggling applications. Good luck!