与MySQL的注释、Query_cache有关的一个bug

与MySQL的注释、Query_cache有关的一个bug

http://dinglin.iteye.com/blog/1749273

今天有同学问了一个关于注释的问题,顺藤摸瓜发现一个bug,简要说明下。

有关注释的一些QA

Q: MySQL注释有哪些格式

A:MySQL的注释格式有三种,分别是 /**/ -- 和 #。具体参见手册

        

Q:在一些导出文件中见过/*! xxx*/,是不是注释?

A:  需要注意的是/*! */ 这种格式,对于MySQL来说不是注释,是能够直接执行的。同时这个格式还支持指定版本号,比如/*!50518 xxxx*/ 表示,若server端版本大于5518,则后续的xxxx作为语句的一部分执行,否则忽略。

 

Q:语句中的注释会不会发给server

A:默认是不会的。一种方法是在mysql连接中加-c (--comments)参数,则会强制将注释部分也发给Server端。 另一种方法与上一条答案有关,指定一个超过server端的版本号。如果比如指定 /*!121221 xxxx*/,也可以发给server。

 

Q: 慢查询日志会不会记录注释部分

A: 慢查询会记录语句原文,如果用上面说到的两种方法将注释发给server,若记录到慢查询日志中,就会显示。(也许可以用这种方法来加入语句来源,做业务慢查询分析)

   不只是慢查询,如果使用statement格式的binlog,注释部分也会写入到binlog中。

 

Q: 使用注释的语句能不能使用Query_cache(QC)

A:可以的,QC 会用原文作key,因此若有注释,则注释部分也要求一模一样才会命中QC

 

Query_cache小背景

QC是一个hash表,key是语句原文,value是查询结果。因此要求一模一样的语句才会命中。

 

Bug描述

若你的语句中是这么写select * from t /*!121221 just test*/. 按照上面说到的,这个语句是会被全文发到server端,不用怕语法错误,因为121221这个版本号大于现有的所有可用版本。因此实际执行的是select * from t;

 

如果query_cache正常打开,会看到第一次执行后show status like 'qcache_inserts';值确实+1.

然后再次执行,发现Qcache_hits并没有+1,反而是Qcache_not_cached +1.

说明这个语句虽然被插入QC中,但是却用不上

 

Bug分析

如果这个查询是慢查询,我们可以在慢查询日志中看到,它记录的是 select * from t /* 121221 just test*/。 ‘!’被换成了空格。

这个替换是在解析阶段发生的。

这样就有问题了:

1、  判断QC是否命中是在解析之前,也就是SQL的原文

2、  第一次执行不命中QC,需要执行,执行期间将!替换成空格

3、  结果在插入QC中,但是此时的key,已经是替换过的。

4、  下一次执行使用的仍然是带!的,因此仍然无法命中

 

    一种解决方法

Percona和MariaDB(5.5+)中有一个特性,刚好绕过这个问题。

参数query_cache_strip_comments用于控制QC中是否去掉SQL语句的注释部分。默认是OFF,若打开,插入QC中的是原语句,可以解决这个问题。

 

'!'为什么要替换

这个问题的是由解析器将/*! */替换成/*  */ 造成的。在5.1其实没有这个替换行为(感谢@飞哥最爱白菜 指出)。为什么MySQL要加上这个动作呢?

原因是我们上面提到的,binlog中会记录语句原文,包括/*!VERSION xxx*/的内容。

这样在主从同步时,若VERSION大于主库版本而小于从库版本(官方是承诺向下兼容的),则可能会出现主从执行不一致的问题。

主库发现xxx不会被执行,就做了替换,语句变成 /* VERSION xxx*/,这是个标准的注释,从库也不会执行xxx部分。

因此属于解决bug的时候引入的。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值