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

    1、 QC基本概念

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

    几个说明：

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

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

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

    2、 锁模型

    于是说到锁的粒度。整个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中的缓存项而互锁。

    因此是“全局锁”.[page]
    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消耗。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。