工作原理
查询缓存的原理可以概括如下：
结果集和SQL语句缓存选择操作或处理查询（注释：5.1.17开始支持）；
新的SELECT语句或预处理查询语句首先查询缓存，确定是否有可用的记录集，并确定标准：是否与缓存的SQL语句相同，它是区分大小写的。
查询缓存不能缓存查询语句的记录集，大致有以下几类：
sql_no_cache参数添加到查询语句。
查询语句包含函数获取值，包括自定义等功能，get_lock CURDATE（）（）、伦德（）、convert_tz等等。
查询系统数据库：MySQL，information_schema
查询语句在存储过程中使用会话级变量或本地变量。
锁共享模式，用于UPDATE语句，在查询语句中使用
查询语句类似于SELECT……到导出数据语句中；
事务隔离级别是：在串行化的情况下，所有的查询语句不能被缓存；
临时表上的查询操作；
具有警告信息的查询语句；
不涉及任何表或视图的查询语句；
用户只有一个等级权限列表。
查询缓存的优点和缺点：
不需要对SQL语句进行任何解析和执行，当然，首先必须从查询缓存中直接进行语法分析，以获得查询结果；
查询缓存的判断规则不够智能，提高了查询缓存的使用门槛，降低了查询效率。
查询缓存的使用会增加检查和查询缓存清理记录集的开销，并且有一个SQL语句缓存表，每个表只能有一个相应的全局锁。
配置
是否启用MySQL查询缓存可以通过2个参数：query_cache_type和query_cache_size，任何参数设置为0，这意味着关闭查询缓存功能，但query_cache_type = 0正确的设置建议。
query_cache_type
范围是：0，没有启用查询缓存；
范围是：1 -启用查询缓存，只要它满足查询缓存的要求，客户机的查询语句和记录集漏斗都可以。
其他客户端缓存和使用。
范围是：2——启用查询缓存。只要查询参数添加到查询：sql_cache，和查询缓存时，客户端的查询语句和记录集可以被缓存和其他客户端使用。
query_cache_size
允许你设置query_cache_size 40K的最小值，最大值是几乎没有限制，实际生产环境中应用的经验告诉我们，价值不大，查询缓存命中率更高，也不降低服务器负荷的贡献，但可能得不偿失，甚至增加服务器负载，至于如何设置以下章节，关于推荐的设置：64m；
query_cache_limit
限制查询缓存查询的记录集，可以避免大量的查询记录集占用内存大面积，往往一个小的查询记录集是最有效的缓存记录设置，默认设置为1M，建议修改16k ~ 1024k之间的范围，但最重要的是分析，根据其应用的实际情况，建立了预测；
query_cache_min_res_unit
设置查询缓存以分配内存的最小单元。适当地设置这个参数，我们可以减少请求的内存块分配的数量，但设置得太大可能导致内存碎片数量上升。默认值为4K，并建议设置为1K ~ 16k
Query_cache_wlock_invalidate
参与MyISAM引擎的主要参数，如果一个客户在一个桌上一个写锁的请求，其他客户端发起的，查询对应的记录查询缓存，是否允许查询缓存记录集的信息直接阅读，或者等待写锁释放。默认设置为0，这是允许。
保持
查询区域内的碎片整理
在使用查询缓存一段时间后，内存碎片通常会发生，因此我们需要监视相关的状态值，并定期做内存碎片排序，而碎片整理的操作语句是同花顺查询缓存。
清除查询缓存的数据
这些操作可能触发查询缓存并清空所有缓存信息，以避免在触发或需要时知道如何操作，以及两种命令可以触发查询缓存数据被清空。
（1）重新设置查询缓存；
（2）刷新表；
性能监测
破碎率
查询缓存内存碎片率= qcache_free_blocks / qcache_total_blocks * 100%
命中率
查询缓存命中率=（qcache_hits - qcache_inserts） / qcache_hits * 100%
内存使用
查询缓存的内存使用率=（query_cache_size - qcache_free_memory） / query_cache_size * 100%
qcache_lowmem_prunes
此参数的值在确定查询缓冲区的内存大小是否设置时起着关键作用。它的含义是：查询缓存，查询缓存的信息从查询缓存删除，因为内存不足，和删除算法LRU。
query_cache_min_res_unit
最小的内存分配单元是非常重要的。内存过大会增加内存碎片的概率，这可能太小，可能会增加内存分配的消耗。为此，在系统的平稳运行阶段之后，我们可以参考公式的计算值。
查询缓存的最小内存块=（query_cache_size - qcache_free_memory） / qcache_queries_in_cache
query_cache_size
我们如何决定是否query_cache_size太小或没有我们还需要设置一个值，可作为32m ~ 128m之间的区域。它需要运行一段时间（至少1周），观察在本周国家相关值。
（1）。qcache_lowmem_prunes；
（2）。命中率；
（3）。内存使用率；
如果监测信息获得的命中率平稳运行超过80%，超过80%的内存使用率，以及qcache_lowmem_prunes不断增加的价值，和增加值太大，那么我们查询内存分配缓冲区太小，可适当增加查询缓存的内存大小；
如果监测得到了小于40%的命中率信息的平稳运行，对qcache_lowmem_prunes值也保持了稳定的状态，然后查询缓存设置过大，或业务场景反复查询相同的概率很低，如果同时也发现一定量的释放项目，然后我们必须考虑查询缓存内存小，甚至关闭查询缓存；
业务场景
通过对上述知识的梳理和分析，我们至少知道了查询缓存的以下几点：
查询缓存可以加快查询语句已经被缓存，而正确的记录集可以得到而无需重新分析和执行。
一个包含查询缓存的表，每个表对象都有属于自己全局属性的锁。
如果你做类似的操作如DDL，刷新表，等等，查询缓存的信息，触发相关的表是空的；
表的DML操作对象必须优先考虑是否对相关查询缓存记录的信息必须被清理，和锁等待事件将不可避免地出现。
查询缓存的内存分配问题不可避免地会产生一些内存碎片。
查询缓存对它是否是相同的查询语句非常苛刻，而且它不是智能的。
当我们回到本节的重点时，查询缓存适合什么样的业务场景只要很清楚，查询缓存的上述优点和缺点并不难列出，则业务场景需要：
整个系统以基于阅读的业务为基础，如门户类型、新闻、报表类型、论坛等。
表格对象的查询语句的操作是不经常使用的DML操作。的query_cache_type = 2模式可以使用，然后SQL语句与sql_cache参数指定；
