MySQL 开启 QueryCache 之后所带来的负面影响： Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。 a) Query 语句的hash 运算以及hash 查找资源消耗。当我们使用Query Cache 之后，每条SELECT类型的Query 在到达MySQL 之后，都需要进行一个hash 运算然后查找是否存在该Query 的Cache，虽然这个hash 运算的算法可能已经非常高效了，hash 查找的过程也已经足够的优化了，对于一条Query 来说消耗的资源确实是非常非常的少，但是当我们每秒都有上千甚至几千条Query 的时候，我们就不能对产生的CPU 的消耗完全忽视了。 b) Query Cache 的失效问题。如果我们的表变更比较频繁，则会造成Query Cache 的失效率非常高。这里的表变更不仅仅指表中数据的变更，还包括结构或者索引等的任何变更。也就是说我们每次缓存到Query Cache 中的Cache 数据可能在刚存入后很快就会因为表中的数据被改变而被清除，然后新的相同Query 进来之后无法使用到之前的Cache。 c) Query Cache 中缓存的是Result Set ，而不是数据页，也就是说，存在同一条记录被Cache 多次的可能性存在。从而造成内存资源的过渡消耗。当然，可能有人会说我们可以限定QueryCache 的大小啊。是的，我们确实可以限定Query Cache 的大小，但是这样，Query Cache 就很容易造成因为内存不足而被换出，造成命中率的下降。 虽然Query Cache 的使用会存在一些负面影响，但是我们也应该相信其存在是必定有一定价值。我们完全不用因为Query Cache 的上面三个负面影响就完全失去对Query Cache 的信心。只要我们理解了Query Cache 的实现原理，那么我们就完全可以通过一定的手段在使用Query Cache 的时候扬长避短，重发发挥其优势，并有效的避开其劣势。 首先，我们需要根据Query Cache 失效机制来判断哪些表适合使用Query 哪些表不适合。由于QueryCache 的失效主要是因为Query 所依赖的Table 的数据发生了变化，造成Query 的Result Set 可能已经有所改变而造成相关的Query Cache 全部失效，那么我们就应该避免在查询变化频繁的Table 的Query 上使用，而应该在那些查询变化频率较小的Table 的Query 上面使用。MySQL 中针对Query Cache 有两个专用的SQL Hint（提示）：SQL_NO_CACHE 和SQL_CACHE，分别代表强制不使用Query Cache 和强制使用Query Cache。我们完全可以利用这两个SQL Hint，让MySQL 知道我们希望哪些SQL 使用Query Cache 而哪些SQL 就不要使用了。这样不仅可以让变化频繁Table 的Query 浪费Query Cache 的内存，同时还可以减少Query Cache 的检测量。 其次，对于那些变化非常小，大部分时候都是静态的数据，我们可以添加SQL_CACHE 的SQL Hint，强制MySQL 使用Query Cache，从而提高该表的查询性能。 最后，有些SQL 的Result Set 很大，如果使用Query Cache 很容易造成Cache 内存的不足，或者将之前一些老的Cache 冲刷出去。对于这一类Query 我们有两种方法可以解决，一是使用SQL_NO_CACHE 参数来强制他不使用Query Cache 而每次都直接从实际数据中去查找， 另一种方法是通过设定“query_cache_limit”参数值来控制Query Cache 中所Cache 的最大Result Set ，系统默认为1M（1048576）。当某个Query 的Result Set 大于“query_cache_limit”所设定的值的时候，QueryCache 是不会Cache 这个Query 的。