MYSQL Query Cache

Query cache:

The result of a SELECT statement is cached, and the next time the same SELECT statement is run, the data can be returned directly, skipping parsing, execution, and optimization phases.

1, the query cache will track the tables involved in the query, if the table changes, the relevant cache will be invalidated.

2, query slow whether hit, is based on the SELECT statement or according to the hash value of the select to be determined.

Example:

(1) Select X from Table_a; ---hash----> 5

(2) Select X

from Table_a; ---hash-----> 9

These two SELECT statements seem to have the same logic in humans, but MySQL doesn't think so, and it thinks the two are different.

The reason is that the first statement has only one row and the second has two rows. Even one more space it will say is not the same, it is the same or not

In terms of the hash value. The hash value is also associated with the location of the cache table, so the second select does not have a way to use the first cache.

A consistent writing style speeds up the query.

3. When the query includes any indeterminate data, it will not be cached. If the inclusion of new (), current_date ();

4, the cache is based on the SELECT statement, and only just received the SQL statement to check if there is a corresponding cache.

So the stored procedure and subquery are out of the way.

Summarize:

It is not a ' silver bullet ', for example, if the table is updated or inserted, the previous cache is useless. Oh, hell, yes. A table corresponding to the cache general

More than one. Even if this is the case, most of the data can improve performance.

MYSQL Query Cache