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 产生太多顾虑。但是,当综合这三个负面影响一起考虑的话,就必须重视了