缓存存放在一个应用表中，通过一个哈希值应用，这个哈希值包括了如下因素，查询本身，当前要查询的数据库，客户端协议的版本等一些其他可能会影响返回结果的信息。

 

当判断缓存是否命中时，Mysql不会解析，“正规化”或者参数化查询语句，而是直接适用SQL语句和客户端发送过来的其他原始信息。任何字符上的不同，例如空额，注释等都会导致缓存的不命中，所以统一的编码规则是一个好的习惯。

 

检查缓存的时候并没有解析SQL语句，所以Mysql并不知道查询语句中是否包含不确定函数。在检查缓存之前，Mysql就做一件事情，就是通过一个大小写不敏感的检查看看SQL是不是以SEL开头。

 

不过也有一些问题需要注意。首先，打开查询缓存对读和写操作都会带来额外的消耗：

读查询在开始之前必须先检查是否命中缓存

如果这个读查询可以被缓存，那么当执行后，Mysql若发现查询缓存没有这个查询，会将其结果存入查询缓存，带来额外的系统消耗

这对写操作也会有影响，因为当向某个表写入数据的时候，Mysql必须将对应表的所有缓存都设置失效。如果查询缓存非常大或者碎片很多，这个操作可能带来很大的系统消耗。

 

虽然如此，查询缓存仍然可能给系统带来性能提升。但是，如上所述，这些额外消耗也可能不断增加，再加上对查询缓存操作是一个加锁排他操作，这个消耗可能不容小觑。

对InnoDB用户来说，事务的一些特性会限制查询缓存的使用。当一个语句在事务中修改了某个表，mysql会将这个表的 对应查询缓存都设置失效。而事实上，InnoDB的多版本特性会展示将这个修改对其他事务屏蔽。在这个事务提交之前，这个表的相关查询是无法被缓存的。所以所有在这个表上的查询——内部或者外部的事务——都只能在该事务提交后才被缓存。因此，长时间运行的事务，会大大降低查询缓存的命中率。