线上环境到底要不要开启query cache

对于大多数读者而言，缓存一般都是放在服务层，用来提高相应速度以及在高并发时可以保护数据源（如mysql）。然而在mysql中，也提供相似的缓存策略即：Query Cache，以下简称QC。在QC中，以查询条件为KEY，其产生的数据结果为VALUE。和大多数的缓存一样，当数据变化不频繁时，比较适用。在InnoDB中，缓存数据存储在Buffer Pool中，在MyISAM中，缓存数据存储在key buffer中。

在表数据发生变化的时候，如DELETE， UPDATE，INSERT等操作的时候，QC需要缓存最新的结果，所以这些操作都会触发QC被刷新。

根据MySQL官方的测试，QC的优劣分别是：

1、如果对一个表执行简单的查询，但每次查询都不一样的话，打开QC后，性能反而下降了13%左右。但通常实际业务中，通常不会只有这种请求，因此实际影响应该比这个小一些。

2、如果对一个只有一行数据的表进行查询，则可以提升238%，这个效果还是非常不错的。

可以看出，在更新频率非常低，查询频率非常高时，打开QC对性能体能还是非常明显的，而且QC一般维持在100MB左右。其他场景，打开QC有可能会降低性能，所以QC的启用与否，还是需要结合具体场景具体分析决定。

值得注意的是，QC中的“KEY”即查询条件，包括SQL语句，连接的数据库、协议版本、字符集等等，任何一个因素发生改变后，都会被认为是全完不一样的“KEY”,从而会使用不同的QC内存块。

此外，QC也不适用于下面几个场景：

子查询或者外层查询；

存储过程、存储函数、触发器、event中调用的SQL，或者引用到这些结果的；

包含一些特殊函数时，例如：BENCHMARK()、CURDATE()、CURRENT_TIMESTAMP()、NOW()、RAND()、UUID()等等；

读取mysql、INFORMATION_SCHEMA、performance_schema 库数据的；

类似SELECT…LOCK IN SHARE MODE、SELECT…FOR UPDATE、SELECT..INTO OUTFILE/DUMPFILE、SELECT..WHRE…IS NULL等语句；

SELECT执行计划用到临时表（TEMPORARY TABLE）；

未引用任何表的查询，例如 SELECT 1+1 这种；

产生了 warnings 的查询；

SELECT语句里加了 SQL_NO_CACHE 关键字；

值得注意的是，MYSQL的QC是和用户权限相关的，MySQL在从QC中取回结果前，会先判断执行SQL的用户是否有全部库、表的SELECT权限，如果没有，则也不会使用QC。最为重要的是，在MySQL里QC是由一个全局锁在控制，每次更新QC的内存块都需要进行锁定。

例如，一次查询结果是20KB，当前 query_cache_min_res_unit 值设置为 4KB（默认值就是4KB，可调整），那么么本次查询结果共需要分为5次写入QC，每次都要锁定，可见其成本有多高。

我们可以通过 PROFILING 功能来查看 QC 相关的一些锁竞争，例如像下面这样的：

或者，也可以通过执行 SHOW PROCESSLIST 来看线程的状态，例如：

• checking privileges on cached query

检查用户是否有权限读取QC中的结果集

• checking query cache for query

检查本次查询结果是否已经存储在QC中

• invalidating query cache entries

由于相关表数据已经修改了，因此将QC中的内存记录被标记为失效

• sending cached result to client

从QC中，将缓存后的结果返回给客户程序

• storing result in query cache

将查询结果缓存到QC中

如果可以频繁看到上述几种状态，那么说明当前QC基本存在比较重的竞争。

说了这么多废话，其实核心要点就一个：

如果线上环境中99%以上都是只读，很少有更新，再考虑开启QC吧，否则，就别开了。

关闭方法很简单，有两种：

1、同时设置选项 query_cache_type = 0 和 query_cache_size = 0；

2、如果用源码编译MySQL的话，编译时增加参数 --without-query-cache 即可；