MySQL · 捉虫动态 · ORDER/GROUP BY 导致 mysqld crash

问题描述

表结构如下所示:

show create table test\G
       Table: test
Create Table: CREATE TABLE `test` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `id2` varchar(50) DEFAULT NULL
  `id3` varchar(100) DEFAULT NULL
  `some_text` varchar(200) DEFAULT NULL
  `name` varchar(20) DEFAULT NULL
  `another_text` varchar(500) DEFAULT NULL
  `ctime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1024 DEFAULT CHARSET=utf8

对 mysql 执行如下语句:

select count(distinct(id2))
from santo_test
where id3 = 'hahaha'
group by substr(ctime, 0, 10)

会导致mysql crash(signal 11)。

崩溃堆栈如下:

pthread_kill ()
handle_segfault (sig=11)
 <signal handler called>
ptr_compare ()
queue_insert ()
merge_buffers()
merge_many_buff()
filesort()
create_sort_index()
JOIN::exec()
mysql_select()
handle_select()
execute_sqlcom_select()
mysql_execute_command()
mysql_parse()
...

官方bug传送

Bug复现小贴士
一条select语句搞挂MySQL Server? 当然还是需要苛刻条件的:

  • 需要保证 sort by/group by 的列本身是 CHAR(0) NOT NULL, 值也要多样化, 不然会直接在优化器被优化掉;
  • 接着该列不能有索引, 确保逻辑走到filesort(在对索引列做GROUP BY/ORDER BY时直接走索引);
  • 之后要配备足够小的sort_buffer_size, 和足够量大的数据撑满 sort_buffer,如@@sort_buffer_size = 32768时,40行数据就可以触发;
  • 然后默默的给 substr 函数投喂错误的参数。

BOOM!

搞完破坏, 我们来看问题怎么解。

成因解析

在看到触发 crash 语句的时候,一定有读者发现哪里不对了。这里使用的 substr(some_string, 0, some_length) 这样的写法,而官方文档中 substr 函数的 @param2 实际上是从1开始计算,当起始位置置为0的时候,这条语句返回值其实是空的。当然,最终导致压坏 mysql server 的一根稻草,正是这个长度为0的字符串。

现在我们沿着执行路线来探索 mysql 是如何一步步挂掉的,在 select 语句中使用 order by/group by 语句时,server 通常调用排序,主要通过索引或者 filesort 来实现排序,在 group by/order by 的列上不存在索引时,server 会选择使用 filesort,其主要逻辑见 filesort.cc:filesort()。这里还会涉及到一个变量,sort_buffer_size,当需要排序的数据量超过sort_buffer_size 大小时,server 会将数据划分为 trunks,这时调用 merge_many_buffers()。随后一路调用到 mysys/ptr_cmp.c 文件中的比较函数,这里的比较函数是按字节进行的,每四个字节为一个比较单位,当传入的参数长度小于4时,会调用 ptr_compare(),而在上节的调用栈可以看到,最后 crash 就是在这个函数里。函数槽点如下:

static int ptr_compare(size_t *compare_length, uchar **a, uchar **b)
{
  reg3 int length= *compare_length;
  reg1 uchar *first,*last;

  first= *a; last= *b;
  while ( --length)
  {
    if (*first++ != *last++)
      return (int) first[-1] - (int) last[-1];
  }
  return (int) first[0] - (int) last[0];
}

在 lengh == 0 时,while 里就会根本停不下来,直到被比较的两位指针不停自加到一个不能访问的内存区域,逼迫系统用 signal 11 杀死 mysql server。

解决方案

比较长度为0的字符串本身是个意外, 所以解决方案就是添加一个辅助函数 ptr_compare_length_zero,在 length 为0时直接返回0,在做排序函数分派时,将长度为0的比较指派到ptr_compare_length_zero
因此,想搞挂MySQL Server,这条路已经被堵上了,还是多修bug少搞破坏比较好 :-)

  1. 官方fix160c6920509516a1e05b855799479a59c27803191
  2. 官方fix2 b62c5daa646434290c9b2d1c9b162487cb8edf04
  3. MySQL · 社区动态 · MySQL5.6.26 ReleaseNote解读
时间: 2024-09-17 12:05:51

MySQL · 捉虫动态 · ORDER/GROUP BY 导致 mysqld crash的相关文章

MySQL · 捉虫动态 · left-join多表导致crash

有一天小编胡乱写SQL, left join了30张表, 结果导致了Mysql server gone away- 我们来看看crash堆栈 <signal handler called> base_list_iterator::next update_ref_and_keys make_join_statistics JOIN::optimize mysql_execute_select 可以看出, 在产生执行计划过程中crash了. 追查 堆栈表明, update_ref_and_keys

MySQL · 捉虫动态 · order by limit 造成优化器选择索引错误

问题描述 bug 触发条件如下: 优化器先选择了 where 条件中字段的索引,该索引过滤性较好: SQL 中必须有 order by limit 从而引导优化器尝试使用 order by 字段上的索引进行优化,最终因代价问题没有成功. 复现case 表结构 create table t1( id int auto_increment primary key, a int, b int, c int, key iabc (a, b, c), key ic (c) ) engine = innod

MySQL · 捉虫动态 · ALTER IGNORE TABLE导致主备不一致

背景 我们知道当一张表的某个字段存在重复值时,这个字段没办法直接加UNIQUE KEY,但是MySQL提供了一个 ALTER IGNORE TABLE的方式,可以忽略修改表结构过程中出现的错误,但是要忽略UNIQUE重复值,就需要打开old_alter_table,也就是拷贝表的方式来ALTER TABLE. 例如这样: CREATE TABLE t1(c1 int) ENGINE = InnoDB; INSERT INTO t1 VALUES (1), (1); SET old_alter_t

MySQL · 捉虫动态 · 删除索引导致表无法打开

问题背景 最近线上遇到一个问题,用户重启实例后发现有张表打不开了,经调研后发现是用户之前的霸蛮操作导致的,下面给出复现步骤: create table t1 (id int not null primary key, name varchar(100) not null) engine=innodb; create table t2 (id int not null primary key, fid int not null, name varchar(100) not null, CONSTR

MySQL · 捉虫动态 · 5.6中ORDER BY + LIMIT 错选执行计划

问题描述 create table t1(id int auto_increment primary key, a int, b int, c int, v varchar(1000), key iabc(a,b,c), key ic(c)) engine = innodb; insert into t1 select null,null,null,null,null; insert into t1 select null,null,null,null,null from t1; insert

MySQL · 捉虫动态 · Relay log 中 GTID group 完整性检测

bug背景 官方 5.7.6 版本对 gtid 有非常多的改进和bugfix,其中有一个 bugfix 是针对 relay log 中没有接收完整的 gtid 事务的.正常的relay log 中的 gtid 事务应该是像下面这样: 1. gtid event 2. query event (begin) 3. row event (write/update/delete) 4. query event (commit) 上面这 4 个 event 序列构成一个 group.因为 IO 线程从主

MySQL · 捉虫动态 · MySQL 外键异常分析

外键约束异常现象 如下测例中,没有违反引用约束的插入失败. create database `a-b`; use `a-b`; SET FOREIGN_KEY_CHECKS=0; create table t1(c1 int primary key, c2 int) engine=innodb; create table t2(c1 int primary key, c2 int) engine=innodb; alter table t2 add foreign key(c2) referen

MySQL · 捉虫动态 · MySQL DDL BUG

背景 MySQL保存了两份元数据,一份在server层,保存在FRM文件中,另外一份在引擎层,比如InnoDB的数据字典中,这样也就造成了DDL语句经常导致元数据不一致的情况,下面介绍两个近期出现的因为DDL产生的bug. rename 外键引用的column BUG复现过程 CREATE TABLE t1 (a INT NOT NULL, b INT NOT NULL, INDEX idx(a)) ENGINE=InnoDB; CREATE TABLE t2 (a INT KEY, b INT

MySQL · 捉虫动态·DROP DATABASE外键约束的GTID BUG

背景 MySQL的DDL没有被设计成事务操作,因此DDL操作是无法回滚的(像PgSQL把DDL也设计成事务操作,DDL就可以在执行成功后被回滚操作取消).这就会导致如果某个DDL语句内部被拆分为多个原子的DDL调用,那么这个DDL语句就不具备中途执行失败后回滚整个DDL语句的能力,也就是说,即使语句逻辑内的某个原子DDL调用失败了,也无法回滚已经完成的那些原子DDL调用. 问题描述 DROP DATABASE 就是一个例子,对于MySQL而言,DROP DATABASE 并非是一个原子DDL操作