对于mysql的query_cache认识的误区

一直以来，对于mysql的query_cache，在网上就流行着这样的说法，“对于mysql的query_cache键值就是mysql的query,所以，如果在query中有任何的不同，包括多了个空格，都会导致mysql认为是不同的查询”，其实，这一种说法是不完全正确的。首先第一点，mysql的query_cache的键值并不是简单的query，而是query加databasename加flag。这个从源码中就可以看出。在这里不做重点描述，后续可以针对于这一点再具体分析。重要的是第二点，是不是加了空格，mysql就认为是不同的查询呢？实际上这个是要分情况而言的，要看这个空格加在哪。 如果空格是加在query之前，比如是在query的起始处加了空格，这样是丝毫不影响query cache的结果的，mysql认为这是一条query, 而如果空格是在query中，那会影响query cache的结果,mysql会认为是不同的query。

下面我们通过实验及源码具体分析。首先，我们先试验一下：

首先，我们看一下mysql query_cache的状态：

首先，我们可以确认，mysql的query_cache功能是打开的。

其次，我们看一下状态：

因为这个db是新的db，所以hits，inset都为0，现在我们执行一条select语句：

 

状态变为：

可以看到，执行一条select后，现在的qcache状态为，insert+1，这样我们就可以推断出，现在刚才那条select语句已经加入了qcache中。那我们现在再将刚才那条sql前面加上空格，看看会怎样呢？

请注意，这条sql，比刚才那条sql前面多了一个空格。

按照网上的理论，这条sql应该会作为另一个键而插入另一个cache，不会复用先前的cache,但结果呢？

我们可以看到，hits变为了1，而inserts根本没变，这就说明了，这条在前面加了空格的query命中了没有空格的query的结果集。从这，我们就可以得出结论，网上先前流传的说法，是不严谨的。

 

那究竟是怎么回事呢？到底应该如何呢？为什么前面有空格的会命中了没有空格的query的结果集。其实，这些我们可以通过源码获得答案。

翻看下mysql的源码，我这翻看的是5.1的，在send_result_to_client（这个函数既是mysql调用query_cache的函数）这个函数里面有这样一段，/*

      Test if the query is a SELECT
      (pre-space is removed in dispatch_command).
 
      First '/' looks like comment before command it is not
      frequently appeared in real life, consequently we can
      check all such queries, too.
    */
    if ((my_toupper(system_charset_info, sql[i])     != 'S' ||