概述
查询 缓存 （Query Cache，简称QC），存储SELECT语句及其产生的数据结果。闲来无事，做一下这块的总结，也做个备忘！
工作原理
查询缓存工作原理如下：
缓存SELECT操作的结果集和SQL语句，key为sql，value为查询结果集；
如果新的SELECT语句到了，以这个sql为key去缓存中查询，如果匹配，就把缓存的结果集返回；
匹配标准：与缓存的SQL语句是否完全一样，sql中字母区分大小写以及中间的空格，简单理解为存储了一个key-value结构，key为sql，value为sql查询结果，匹配时使用Java的String的equals()，例如：
select age from user 与 select AGE from user不会匹配，因为大小写不同； select age from use 与 select age from user不会匹配，因为空格不同；
sql两边的空格可忽略，可以认为是对key进行过 trim 操作之后再进行equals比较。
查看 mysql 设置参数
执行
show variables like '%query_cache%';
可以看到相关参数：
query_cache_type：0-不启用查询缓存；1-启用，2-启用，默认值为0； query_cache_size：设置缓存区总大小，允许设置query_cache_size的值最小为40K，默认1M，推荐设置为：64M/128M； query_cache_limit：限制缓存区最大能缓存的单条查询记录集大小，默认设置为1M
query_cache_type为1时，只要符合查询缓存的要求，客户端的查询语句和记录集都可以缓存起来，如果SQL中加上 SQL_NO_CACHE将不缓存；
query_cache_type为2时，只要SQL中添加了参数：SQL_CACHE，且符合查询缓存的要求，客户端的查询语句和记录集，则可以缓存起来。
查看缓存使用情况
show status like '%Qcache%%';
可以看到相关参数：
Qcache_hits：缓存命中次数； Qcache_inserts：缓存中插入次数，每缓存一次加1，注意这个不是缓存数量；
开启查询缓存
设置选项query_cache_type = 1 ，同时设置query_cache_size = 67108864；
注：query_cache_size的值设置在100MB以内即可。在MySQL里查询缓存是由一个全局锁在控制，每次更新查询缓存的内存块都需要进行锁定。
关闭查询缓存
设置选项query_cache_type = 0，同时设置query_cache_size = 0。
适用场景
用于频繁提交同一个语句，并且该表数据变化不是很频繁的场景，例如一些静态页面，或者页面中的某块不经常发生变化的信息。
由于查询缓存需要缓存最新数据结果，因此表数据发生任何变化（insert、update、delete或其他可能产生数据变化的操作），都会导致查询缓存被刷新。因而，对于一个更新频率非常低而只读查询频率非常高的场景下，打开查询缓存还是比较有优势的。
不适用场景
查询缓存严格要求2次SQL请求要完全一样，包括SQL语句，连接的数据库、协议版本、字符集等因素都会影响。下面为查询缓存不适用的几个场景：
- 子查询；
- 过程、函数、触发器、event中调用的SQL，或者引用到这些结果的；
- 查询中涉及一些特殊函数时，例如：BENCHMARK()、CURDATE()、CURRENT_TIME()、CURRENT_TIMESTAMP()、NOW()、SLEEP()、CONNECTION_ID()、CURRENT_DATE()、CURRENT_USER()、PASSWORD()、RAND()、UUID()、ENCRYPT()、LAST_INSERT_ID()等等；
- 查询涉及到mysql，information_schema或performance_schema。
- 类似SELECT…LOCK IN SHARE MODE、SELECT…FOR UPDATE、SELECT..INTO OUTFILE/DUMPFILE、SELECT * FROM … WHERE autoincrement_col IS NULL的查询；
- SELECT执行计划用到临时表；
- 未引用任何表的查询，例如SELECT 1+2；
- 查询产生了告警(warnings)；
- SELECT语句中存在SQL_NO_CACHE关键字；
- 涉及到分区表。
可见，使用查询的缓存的限制非常多。当使用场景中以只读为主，很少有更新的情况时，再考虑开启查询缓存。
后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~
