MySQL 的Query Cache 实现原理实际上并不是特别的复杂，简单的来说就是将客户端请求的Query语句（当然仅限于SELECT 类型的Query）通过一定的hash 算法进行一个计算而得到一个hash 值，存放在一个hash 桶中。同时将该Query 的结果集（Result Set）也存放在一个内存Cache 中的。存放Query hash 值的链表中的每一个hash 值所在的节点中同时还存放了该Query 所对应的Result Set 的Cache 所在的内存地址，以及该Query 所涉及到的所有Table 的标识等其他一些相关信息。系统接受到任何一个SELECT 类型的Query 的时候，首先计算出其hash 值，然后通过该hash 值到Query Cache 中去匹配，如果找到了完全相同的Query，则直接将之前所Cache 的Result Set 返回给客户端而完全不需要进行后面的任何步骤即可完成这次请求。而后端的任何一个表的任何一条数据发生变化之后，也会通知QueryCache，需要将所有与该Table 有关的Query 的Cache 全部失效，并释放出之前占用的内存地址，以便后面其他的Query 能够使用。
从上面的实现原理来看，Query Cache 确实是以比较简单的实现带来巨大性能收益的功能。但是很多人可能都忽略了使用QueryCache 之后所带来的负面影响：
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 产生太多顾虑。但是，当综合这三个负面影响一起考虑的话，就必须重视了