顾名思义，MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说，Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲，就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。
MySQL Query Cache几个说明：
a） QC的结构是hash,key为查询字符串的原文，因此若想命中QC,要求查询语句与之前的一模一样，包括大小写必须一致、不能增减空格等等。
b） Qc可以缓存一个表中的多个查询语句和结果。
c） 对一个表的DML或DDL操作都会将与这个表有关的缓存都从QC中删除。
1、 锁模型
于是说到锁的粒度。整个QC在内存中只有一个实例Query_cache query_cache;
我们来看上面c中说到的失效逻辑的部分代码
void Query_cache::invalidate_table（THD *thd, uchar * key, uint32 key_length）{ DEBUG_SYNC（thd, “wait_in_query_cache_invalidate1″）；
lock（）；
DEBUG_SYNC（thd, ”wait_in_query_cache_invalidate2″）；
if （query_cache_size > 0）
invalidate_table_internal（thd, key, key_length）；
unlock（）；
}
可以看到这里lock（）没有参数，函数内部用一额全局信号量COND_cache_status_changed,来控制。
因此即使两个dml更新的是不同的表，也会由于都要失效本表在QC中的缓存项而互锁。
因此是“全局锁”.
2、锁策略
得到上述结论后我们有点担心，作为一个全局变量，是否也会锁住“查询”.试想如果我们在作一个DDL时，需要失效这个表的缓存项，而这个锁的时间就会持续很长。 这期间其他表的普通查询，是否也会受影响。 如果是，这个损失太大了。
我们知道，查询过程中的对QC的访问包含两部分 :查询开始之前从QC中判断当前Query的结果是否已经缓存； 若没有，则查询执行完成后，（可能）需要将这个结果插入到QC中。
这两个操作都其实也都需要对QC加锁。这样说来， 这个锁的频度如此之高，以至于我们会担心是否会得不偿失？
更新时失效缓存项是必要的操作，但查询时对QC的操作则不是必须的。MySQL中使用try_lock的策略。简单来说，就是在上面的两个阶段中，试图去加锁，若超时，则放弃。
这个超时时间写死在代码中是50ms,所以若一个 查询期间的两次对QC的操作都出现锁超时，则这个查询会额外耗费100ms的时间。
当然若是dml操作需要失效QC中的项，而碰上锁等待，就必须等了。
总之，当MySQL数据库开启了 Query Cache 之后，尤其是当我们的 query_cache_type 参数设置为 1 以后，MySQL 会对每个 SELECT 语句都进行 Query Cache 查找，查找操作虽然比较简单，但仍然也是要消耗一些 CPU 运算资源的。而由于 Query Cache 的失效机制的特性，可能由于表上的数据变化比较频繁，大量的 Query Cache 频繁的被失效，所以 Query Cache 的命中率就可能比较低下。所以有些场景下，Query Cache 不仅不能提高效率，反而可能造成负面影响。
