很多时候人们感觉Query Cache是一个能够很好优化数据库的配置。所以在优化数据库是配置Query Cache成为了必然的事情。但Query Cache真的有那么好吗？看来也未必……

    一个上线的项目就被MySQL Query Cache 炕了、线上大量 Waiting on query cache mutex。

看上去很美的 Query Cache。

    从理论来说，的确很完美。QC 缓存的是整个SELECT的结果集、而非执行计划、QC的为人原则是：执行查询最快的方式就是不去执行 但是、QC 简单粗暴的失效策略、令人蛋疼、任何不同(空格、TAB缩进、DML等)都会导致该表的Cache不可用失效通过single mutex 控制、有比较严重的锁竞争

     如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之这里“数据表更改”包 括: INSERT, UPDATE,DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等
     
     如何关闭QC？
     控制 2个参数：
     ① query_cache_type = off
     ② query_cache_size = 0
     
     总体而言、QC不建议使用、鸡肋功能、"夫鸡肋，弃之如可惜，食之无所得"、导致几十上百倍的性能差异如果、确实有这个缓存需求、应用允许的情况下、可用效率高的Redis或者MC等替代