MySQL查询缓存

简介

大多数的 MySQL 服务器都开启了查询缓存。这是提高性能最有效的方法之
一，而且是由MySQL 数据库引擎进行处理的。当有很多相同的查询被执行了多
次的时候，这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不
用操作表而直接访问缓存结果了。

使用场景

用于频繁提交同一个语句，并且该表数据变化不是很频繁的场景，例如一些静态页面，或者页面中的某块不经常发生变化的信息。

由于查询缓存需要缓存最新数据结果，因此表数据发生任何变化（insert、update、delete或其他可能产生数据变化的操作），都会导致查询缓存被刷新。因而，对于一个更新频率非常低而只读查询频率非常高的场景下，打开查询缓存还是比较有优势的。

不适用场景

查询缓存严格要求2次SQL请求要完全一样，包括SQL语句，连接的数据库、协议版本、字符集等因素都会影响。下面为查询缓存不适用的几个场景：

1. 子查询；
2. 过程、函数、触发器、event中调用的SQL，或者引用到这些结果的；
3. 查询中涉及一些特殊函数时，例如：BENCHMARK()、CURDATE()、CURRENT_TIME()、CURRENT_TIMESTAMP()、NOW()、SLEEP()、CONNECTION_ID()、CURRENT_DATE()、CURRENT_USER()、PASSWORD()、RAND()、UUID()、ENCRYPT()、LAST_INSERT_ID()等等；
4. 查询涉及到mysql，information_schema或performance_schema。
5. 类似SELECT…LOCK IN SHARE MODE、SELECT…FOR UPDATE、SELECT…INTO OUTFILE/DUMPFILE、SELECT * FROM … WHERE autoincrement_col IS NULL的查询；
6. SELECT执行计划用到临时表；
7. 未引用任何表的查询，例如SELECT 1+2；
8. 查询产生了告警(warnings)；
9. SELECT语句中存在SQL_NO_CACHE关键字；
10. 涉及到分区表。

可见，使用查询的缓存的限制非常多。当使用场景中以只读为主，很少有更新的情况时，再考虑 。

操作

1. 查询缓存状态：
   执行 show variables like ‘%query_cache%’; 语句，查询结果如下（query_cache_type 为 ON 表示已经开启）：
   
2. 修改配置文件my.ini
   windows下是my.ini，linux下是my.cnf;
   在配置文件的最后追加上：

query_cache_type = 1
query_cache_size = 600000

3. 执行SQL

set global query_cache_type = 1;  
set global query_cache_size = 600000;

注意：上述两种开启缓存的方式都需要重启mysql才能生效。

4. 查看缓存使用情况
   执行 show status like ‘qcache%’; SQL语句，结果如下：
   
   参数说明：

• Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。
• Qcache_free_memory：缓存中的空闲内存。
• Qcache_hits：每次查询在缓存中命中时就增大
• Qcache_inserts：每次进行查询时就增大。命中次数除以插入次数就是不中比率。
• Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个 数字在不断增长，就表示可能碎片非常严重，或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况)
  Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。
• Qcache_queries_in_cache：当前缓存的查询(和响应)的数量。
• Qcache_total_blocks：缓存中块的数量。

5. 对于某些不想使用缓存的语句，可以这样使用：
   select SQL_NO_CACHE count(*) from users where email = ‘hello’;

参考：
https://www.cnblogs.com/baker95935/p/7710115.html
http://blog.itpub.net/26736162/viewspace-2692161/
https://www.cnblogs.com/haitaoli/p/10828564.html