对于mysql的query_cache认识的误区

其实,这一种说法是不完全正确的。首先第一点,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' ||
my_toupper(system_charset_info, sql[i + 1]) != 'E' ||
my_toupper(system_charset_info, sql[i + 2]) != 'L') &&
sql[i] != '/')
{
DBUG_PRINT("qcache", ("The statement is not a SELECT; Not cached"));
goto err;
}

是在检验语句是否为select语句,重点是上面那段注释。特别是括弧中的,pre-space is removed in dispatch_command,也就是说,在语句开始之前的多余的空格已经被处理过了,在dispache_command这个函数中去掉了。

我们看下dispache_command这个方法,在这个方法里有这样一段:


代码如下:

if (alloc_query(thd, packet, packet_length))
break; // fatal error is set
char *packet_end= thd->query() + thd->query_length();
/* 'b' stands for 'buffer' parameter', special for 'my_snprintf' */
const char* end_of_stmt= NULL;

在这里,会调用alloc_query方法,我们看下这个方法的内容:


代码如下:

bool alloc_query(THD *thd, const char *packet, uint packet_length)
{
char *query;
/* Remove garbage at start and end of query */
while (packet_length > 0 && my_isspace(thd->charset(), packet[0]))
{
packet++;
packet_length--;
}
const char *pos= packet + packet_length; // Point at end null
while (packet_length > 0 &&
(pos[-1] == ';' || my_isspace(thd->charset() ,pos[-1])))
{
pos--;
packet_length--;
}
/* We must allocate some extra memory for query cache
The query buffer layout is:
buffer :==
<statement> The input statement(s)
'\0' Terminating null char (1 byte)
<length> Length of following current database name (size_t)
<db_name> Name of current database
<flags> Flags struct
*/
if (! (query= (char*) thd->memdup_w_gap(packet,
packet_length,
1 + sizeof(size_t) + thd->db_length +
QUERY_CACHE_FLAGS_SIZE)))
return TRUE;
query[packet_length]= '\0';
/*
Space to hold the name of the current database is allocated. We
also store this length, in case current database is changed during
execution. We might need to reallocate the 'query' buffer
*/
char *len_pos = (query + packet_length + 1);
memcpy(len_pos, (char *) &thd->db_length, sizeof(size_t));
thd->set_query(query, packet_length);
/* Reclaim some memory */
thd->packet.shrink(thd->variables.net_buffer_length);
thd->convert_buffer.shrink(thd->variables.net_buffer_length);
return FALSE;
}

这个方法在一开始就会对query进行处理(代码第4行),将开头和末尾的garbage remove掉。
看到这里,我们基本已经明了了,mysql会对输入的query进行预处理,将空格等东西给处理掉,所以不会开头的空格不会影响到query_cache,因为对mysql来说,就是一条query。

(0)

相关推荐

  • 借助PHP的mysql_query()函数来创建MySQL数据库的教程

    以mysql_query()函数作为教程的基础前提,我们先来看一下mysql_query()的用法: mysql_query()函数 PHP MySQL 函数库中,mysql_query() 函数用于向 MySQL 发送并执行 SQL 语句. 对于没有数据返回结果集的 SQL ,如 UPDATE.DELETE 等在执行成功时返回 TRUE,出错时返回 FALSE:对于 SELECT,SHOW,EXPLAIN 或 DESCRIBE 语句返回一个资源标识符,如果查询执行不正确则返回 FALSE. 语

  • 浅谈mysql_query()函数的返回值问题

    问题描述: 我在操作mysql,插入数据时,关闭资源,PHP提示了一个warning.内容大致为,需要给mysql_free_result()一个资源类型. 然后,我将返回的结果var_dump($res),发现是bool值 分析: 看手册时,一眼看上去,觉得mysql_query()函数返回的本来就是资源类型,可是为什么现在又是bool值了呢?好吧,耐心看完手册,才发现,原理是这样的,如下图片: 总结:由上可以知道,mysql_query()执行sql语句时,并不是什么时候都要执行释放结果集,

  • 对于mysql的query_cache认识的误区

    其实,这一种说法是不完全正确的.首先第一点,mysql的query_cache的键值并不是简单的query,而是query加databasename加flag.这个从源码中就可以看出.在这里不做重点描述,后续可以针对于这一点再具体分析.重要的是第二点,是不是加了空格,mysql就认为是不同的查询呢?实际上这个是要分情况而言的,要看这个空格加在哪. 如果空格是加在query之前,比如是在query的起始处加了空格,这样是丝毫不影响query cache的结果的,mysql认为这是一条query,

  • 详解Mysql和Oracle之间的误区

    本质区别 Oracle数据库是一个对象关系数据库管理系统(收费) MySQL是一个开源的关系数据库管理系统(免费) 数据库的安全性 mysql使用三个参数来验证用户,即用户名,密码和位置 Oracle使用了更多的安全功能,如用户名,密码,配置文件,本地身份验证,外部身份验证,高级安全增强功能等 权限 MySQL的权限系统是通过继承形成的分层结构.权限授于高层时,其他低层隐式继承被授于的权限,当然低层也可改写这些权限. 按授权范围不同,MySQL有以下种授权方式: 1.全局: 2.基于每个主机:

  • mysql 性能的检查和优化方法

    1.索引没有建好; 2.sql写法过于复杂; 3.配置错误; 4.机器实在负荷不了; 1.索引没有建好 如果看到mysql消耗的cpu很大,可以用mysql的client工具来检查. 在linux下执行 /usr/local/mysql/bin/mysql -hlocalhost -uroot -p 输入密码,如果没有密码,则不用-p参数就可以进到客户端界面中. 看看当前的运行情况 show full processlist 可以多运行几次 这个命令可以看到当前正在执行的sql语句,它会告知执行

  • mysql 性能的检查和调优方法

    在遇到严重性能问题时,一般都有这么几种可能:1.索引没有建好; 2.sql写法过于复杂; 3.配置错误; 4.机器实在负荷不了; 1.索引没有建好 如果看到mysql消耗的cpu很大,可以用mysql的client工具来检查. 在linux下执行 /usr/local/mysql/bin/mysql -hlocalhost -uroot -p 输入密码,如果没有密码,则不用-p参数就可以进到客户端界面中. 看看当前的运行情况 show full processlist 可以多运行几次 这个命令可

  • MySQL 常见的数据表设计误区汇总

    误区一:过多的数据列 MySQL 存储引擎的 API 是按照行缓冲区方式从服务端和存储引擎复制数据.服务端将缓冲区数据解码成数据列.然而,将行缓冲区的格式转换为数据行数据结构的列可能会代价很高.MyISAM 固定使用与服务端匹配的行格式,因此无需转换.然而,MyISAM 的可变行格式以及 InnoDB 的行格式总是需要进行转换.转换的代价依赖于列的数量.如果当数据表的列超过上百列的时候,会引起很高的 CPU 资源消耗--即便是使用到的列很少.曾经看过一篇文章,指的是一个多语言的解决方案,直接简单

  • Mysql表连接的误区与原理详析

    目录 前言 连接过程简介 内连接与外连接 where 与 on 总结 前言 搞后端的肯定要经常接触到数据库,搞数据库一个避免不了的地方就是 join, join的语法很简单,但是在使用时常常陷入一下两种误区: 误区一: 业务至上,管他三七二十一,再复杂的查询一个连接语句搞定 误区二: 敬而远之,上次写的慢查询sql就是使用了join导致的,以后再也不敢用了 先来举个栗子: mysql> SELECT * FROM t1; +------+------+ | m1 | n1 | +------+-

  • MySQL配置文件my.cnf中文详解附mysql性能优化方法分享

    下面先说我的服务器的硬件以及论坛情况,CPU: 2颗四核Intel Xeon 2.00GHz内存: 4GB DDR硬盘: SCSI 146GB论坛:在线会员 一般在 5000 人左右 – 最高记录是 13264.下面,我们根据以上硬件配置结合一份已经做过一次优化的my.cnf进行分析说明:有些参数可能还得根据论坛的变化情况以及程序员的程序进行再调整.[mysqld]port = 3306serverid = 1socket = /tmp/mysql.sockskip-locking # 避免My

  • mysql 优化日记

    同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法,因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能. 安装好mysql后,配制文件应该在/usr/local/mysql/share/mysql目录中,配制文件有几个,有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的服务器环境

  • SQL Injection with MySQL 注入分析

    声明 本文仅用于教学目的,如果因为本文造成的攻击后果本人概不负责,本文所有代码均为本人所写,所有数据均经过测试.绝对真实.如果有什么遗漏或错误,欢迎来安全天使论坛和我交流. 前言 2003年开始,喜欢脚本攻击的人越来越多,而且研究ASP下注入的朋友也逐渐多了起来,我看过最早的关于SQL注入的文章是一篇99年国外的高手写的,而现在国外的已经炉火纯青了,国内才开始注意这个技术,由此看来,国内的这方面的技术相对于国外还是有一段很大差距,话说回来,大家对SQL注入攻击也相当熟悉了,国内各大站点都有些堪称

  • MySQL 删除大表的性能问题解决方案

    微博上讨论MySQL在删除大表engine=innodb(30G+)时,如何减少MySQL hang的时间,现做一下简单总结: 当buffer_pool很大的时候(30G+),由于删除表时,会遍历整个buffer pool来清理数据,会导致MySQL hang住,解决的办法是: 1.当innodb_file_per_table=0的时候,以上不是问题,因为采用共享表空间的时候,该表所占用的空间不会被删除,buffer pool中的相关页不会 被discard. 2.当innodb_file_pe

随机推荐