有同学在问 MySQL数据库中 QueryCache(QC)的锁是 “全局锁”还是 “表锁”。这里简要说明一下。

1、  QC基本概念

这个是实现在MySQL层(非引擎层)的一个内存结构，基本规则是将满足一定条件的查询结果缓存在内存中，若同样的查询再执行第二次，而且缓存没有失效，则可以直接返回查询结果，无需到引擎获取数据。

几个说明：

a) QC的结构是hash，key为查询字符串的原文，因此若想命中QC，要求查询语句与之前的一模一样，包括大小写必须一致、不能增减空格等等。

b) Qc可以缓存一个表中的多个查询语句和结果。

c) 对一个表的DML或DDL操作都会将与这个表有关的缓存都从QC中删除。

2、  锁模型

于是说到锁的粒度。整个QC在内存中只有一个实例Query_cache query_cache;

我们来看上面c中说到的失效逻辑的部分代码

可以看到这里lock()没有参数，函数内部用一额全局信号量COND_cache_status_changed,来控制。

因此即使两个dml更新的是不同的表，也会由于都要失效本表在QC中的缓存项而互锁。

因此是“全局锁”。

3、锁策略

    得到上述结论后我们有点担心，作为一个全局变量，是否也会锁住“查询”。试想如果我们在作一个DDL时，需要失效这个表的缓存项，而这个锁的时间就会持续很长。 这期间其他表的普通查询，是否也会受影响。 如果是，这个损失太大了。

我们知道，查询过程中的对QC的访问包含两部分 ：查询开始之前从QC中判断当前Query的结果是否已经缓存； 若没有，则查询执行完成后，(可能)需要将这个结果插入到QC中。

这两个操作都其实也都需要对QC加锁。这样说来， 这个锁的频度如此之高，以至于我们会担心是否会得不偿失？

更新时失效缓存项是必要的操作，但查询时对QC的操作则不是必须的。MySQL中使用try_lock的策略。简单来说，就是在上面的两个阶段中，试图去加锁，若超时，则放弃。

     这个超时时间写死在代码中是50ms，所以若一个 查询期间的两次对QC的操作都出现锁超时，则这个查询会额外耗费100ms的时间。

当然若是dml操作需要失效QC中的项，而碰上锁等待，就必须等了。

4、小结

从上面描述中可以得出一些结论，对于更新操作比较小的服务，开启QC的效果会不错，因为查询期间使用的try_lock策略使得不会出现查询在QC阶段互锁的问题。(这个50ms如果觉得太大，可以在源码中去掉个0)。

当然若是更新频繁的表，还是建议关闭QC。现在主干版本上用参数关闭QC不够彻底，还是会有一些cpu消耗。有兴趣的同学可以看这篇 。

建议继续学习：

1. 无锁消息队列    (阅读：12819)
2. 并发编程系列之一：锁的意义    (阅读：5902)
3. 无锁HashMap的原理与实现    (阅读：5352)
4. MySQL锁管理(并发锁,行锁,表锁,预加锁,全局锁等等)    (阅读：4500)
5. DYNAMO平台的独门绝技： 利用NWR模型与vector clock解决锁问题    (阅读：3926)
6. 并行编程中的“锁”难题    (阅读：3761)
7. Linux下互斥量加锁与解锁操作的C代码实现    (阅读：3234)
8. php中读写文件时锁的使用    (阅读：2935)
9. 锁是怎么实现的？    (阅读：2937)
10. lock free的理解    (阅读：2376)