MySQL的match函数在sp中使用的BUG解析

一、问题发现

在一次开发中在sp中使用MySQL PREPARE以后，使用match AGAINST语句作为prepare stmt的参数后，发现执行第二遍call会导致数据库crash，于是开始动手调查问题发生的原因。

注：本次使用的 MySQL 数据库版本为最新的debug版本。

SQL语句示例：

二、问题调查过程

1、首先查看错误堆栈信息，可以看到Item_func_match::val_real函数的item->real_item()->type()不等于FIELD_ITEM引起的，打印堆栈看了一下，此时的item->real_item()为Item_splocal，明显不是FIELD_ITEM。

　　#0 __GI_raise （sig=sig@entry=6） at 。./sysdeps/unix/sysv/linux/raise.c:50

　　#1 0x00007ffff7568859 in __GI_abort （） at abort.c:79

　　#2 0x00007ffff7568729 in __assert_fail_base （fmt=0x7ffff76fe588 “%s%s%s：%u： %s%sAssertion `%s‘ failed.\n%n”，

　　assertion=0x55555bd2e340 “std：：all_of（args， args + arg_count， ［］（const Item *item） { return item-》real_item（）-》type（） == FIELD_ITEM; }）”， file=0x55555bd2a9e0 “/mysql/sql/item_func.cc”，

　　line=9769， function=《optimized out》） at assert.c:92

　　#3 0x00007ffff7579fd6 in __GI___assert_fail （

　　assertion=0x55555bd2e340 “std：：all_of（args， args + arg_count， ［］（const Item *item） { return item-》real_item（）-》type（） == FIELD_ITEM; }）”， file=0x55555bd2a9e0 “/mysql/sql/item_func.cc”，

　　line=9769， function=0x55555bd2e300 “virtual double Item_func_match：：val_real（）”） at assert.c:101

　　#4 0x0000555558f9e17e in Item_func_match：：val_real （this=0x7fff2cc86928） 这里导致的crash

　　at /mysql/sql/item_func.cc:9769

　　#5 0x0000555558f97f7e in Item_func_set_user_var：：check （this=0x7fff2cc88200， use_result_field=false）

　　at /mysql/sql/item_func.cc:8238

　　#6 0x00005555592d74d3 in set_var_user：：check （this=0x7fff2cc88388）

　　at /mysql/sql/set_var.cc:1874

　　#7 0x00005555592d5cd6 in sql_set_variables （thd=0x7fff2c001050， var_list=0x7fff2cc87210， opened=true）

　　at /mysql/sql/set_var.cc:1442

　　#8 0x00005555594d89ed in mysql_execute_command （thd=0x7fff2c001050， first_level=false）

　　at /mysql/sql/sql_parse.cc:4051

　　#9 0x000055555930c7a8 in sp_instr_stmt：：exec_core （this=0x7fff2cc883d8， thd=0x7fff2c001050，

　　nextp=0x7fffe02ed8b4） at /mysql/sql/sp_instr.cc:1039

　　#10 0x000055555930ae0b in sp_lex_instr：：reset_lex_and_exec_core （this=0x7fff2cc883d8， thd=0x7fff2c001050，

　　nextp=0x7fffe02ed8b4， open_tables=false） at /mysql/sql/sp_instr.cc:457

　　#11 0x000055555930bc74 in sp_lex_instr：：validate_lex_and_execute_core （this=0x7fff2cc883d8， thd=0x7fff2c001050，

　　nextp=0x7fffe02ed8b4， open_tables=false） at /mysql/sql/sp_instr.cc:771

　　#12 0x000055555930c3ad in sp_instr_stmt：：execute （this=0x7fff2cc883d8， thd=0x7fff2c001050， nextp=0x7fffe02ed8b4）

　　at /mysql/sql/sp_instr.cc:956

　　#13 0x00005555592fa772 in sp_head：：execute （this=0x7fff2cc76da0， thd=0x7fff2c001050， merge_da_on_success=true）

　　at /mysql/sql/sp_head.cc:2279

　　#14 0x00005555592fcec2 in sp_head：：execute_procedure （this=0x7fff2cc76da0， thd=0x7fff2c001050， args=0x0）

　　at /mysql/sql/sp_head.cc:2995

　　#15 0x00005555593661c9 in do_execute_sp （thd=0x7fff2c001050， sp=0x7fff2cc76da0， args=0x0）

　　at /mysql/sql/sql_call.cc:86

2、要想获取sp参数的实际item，应该调用this_item()方法，但是也许作者本来就不想让match支持sp参数，因此这里的写法是对的。但是本来代码不应该运行到这里，因为本来应该直接报错。

　　double Item_func_match：：val_real（） {

　　assert（fixed）;

　　assert（！has_rollup_expr（））;

　　assert（std：：all_of（args， args + arg_count， ［］（const Item *item） {

　　return item-》real_item（）-》type（） == FIELD_ITEM; ==》这里的item-》real_item（）-》type（）说明不支持Item_splocal

　　}））;

3、接着继续调查，查看第一次报错的地方的代码，找到Item_func_match::fix_fields，看到了第一次报错的地方的代码item->type() != Item::FIELD_ITEM，因此代码运行应该在这里报错。但是为何第二次执行会运行到Item_func_match::val_real而不是在Item_func_match::fix_fields就直接报错返回呢？仔细查看下面的代码，发现下面的代码有1个地方有错误。

三、问题解决方案

通过以上代码解析后作如下修改，正确给fixed赋值，这样就可以保证每次call sp的时候如果遇到报错再次运行还会重新执行fix_fields。

现在重新执行call sp，没有问题了。

　　mysql》 call p1;

　　ERROR 1210 （HY000）： Incorrect arguments to MATCH

　　mysql》 call p1;

　　ERROR 1210 （HY000）： Incorrect arguments to MATCH

四、问题总结

本次只是解决了match的fix_fields问题，但是如果想让match支持 sp 的参数，即Item_splocal的参数的话，代码里面还要做相应修改，包括set @bb := match(a,b) AGAINST ('collections');这里面生成的Item_func_match会在这句执行完以后被 cleanup 掉，等到下一句 prepare 想再次使用它的时候会因为找不到该item发生问题，这个是重构match函数支持 sp 参数需要注意的点。

审核编辑：刘清