mysql's SQL_NO_CACHE (do not use cache at query time) and sql_cache usage

Reprinted from: http://www.169it.com/article/5994930453423417575.html

 

In order to test the efficiency of SQL statements, sometimes it is necessary to query without caching.
use
SELECT SQL_NO_CACHE ...
syntax is enough
 
The real effect of SQL_NO_CACHE is to prohibit caching of query results , but it does not mean that cache does not return results to query.
 
There are only two explanations for SQL_NO_CACHE currently circulating:
1. If the current query does not use the existing cache of the database to query, the current query will take more time
2. If the result set generated by the current query is not cached in the system query cache, the next time the same query will take more time
I did the next experiment and it seems both are correct.
 
sql_cache means that the cache is used when querying.
 
The explanation and test of SQL_NO_CACHE are as follows:
SQL_NO_CACHE means that the query result is not cached. It does not mean that the cache is not used to answer the query.
You may use RESET QUERY CACHE to remove all queries from the cache and then your next query should be slow again. Same effect if you change the table, because this makes all cached queries invalid.
 
mysql> select count(*) from users where email = 'hello';
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (7.22 sec)
 
mysql> select count(*) from users where email = 'hello';
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.45 sec)
 
mysql> select count(*) from users where email = 'hello';
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.45 sec)
 
mysql> select SQL_NO_CACHE count(*) from users where email = 'hello';
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.43 sec)
 

 

=================MyBatis's application of CACHE========================
The use of flushCache and useCache of MyBatis
 
(1) When it is a select statement:
flushCache defaults to false, which means that whenever a statement is called, the local cache and second-level cache will not be emptied.
The default value of useCache is true, which means that the result of this statement will be cached at the second level.
 
(2) When it is an insert, update, delete statement:
flushCache defaults to true, which means that any time a statement is called, the local cache and the second-level cache will be emptied.
The useCache attribute is absent in this case.
When it is a select statement, if flushCache and useCache are not configured, the cache is enabled by default. Therefore, if necessary, you need to manually modify the configuration. The modification results are similar to the following:
 
<select id="save" parameterType="XX" flushCache="true" useCache="false">
……
</select>
 
When updating, if flushCache="false", after you update, the queried data is still the old data.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325309582&siteId=291194637