一、问题发现
在一次开发中在 sp 中应用 MySQL PREPARE
当前,应用 match AGAINST
语句作为 prepare stmt
的参数后,发现执行第二遍 call 会导致数据库 crash,于是开始入手考察问题产生的起因。
注:本次应用的 MySQL 数据库版本为最新的 debug 版本。
SQL 语句示例:
CREATE TABLE t1 (a INT, b VARCHAR(10));
DELIMITER $$
CREATE PROCEDURE p1()
begin
declare a VARCHAR(200);
declare b TEXT;
set a = 'Only MyISAM tables';
set b ='support collections';
set @bb := match(a,b) AGAINST ('collections');
prepare stmt1 from 'select * from t1 where ?';
execute stmt1 using @bb;
end$$
DELIMITER ;
执行后果:mysql> call p1;
ERROR 1210 (HY000): Incorrect arguments to MATCH
mysql> call p1; 这里发现代码 crash 了
ERROR 2013 (HY000): Lost connection to MySQL server during query
二、问题调查过程
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 个中央有谬误。
bool Item_func_match::fix_fields(THD *thd, Item **ref) {if (Item_func::fix_fields(thd, ref) || fix_func_arg(thd, &against) ||
下面这里 Item_func::fix_fields 执行完后使 fixed=true
然而如果前面有任何报错的中央导致返回的话,这个值没有批改回 false
会导致第二次 call sp 不会再次执行 Item_func_match::fix_fields。!against->const_for_execution()) {
thd->mark_used_columns = save_mark_used_columns;
my_error(ER_WRONG_ARGUMENTS, MYF(0), "AGAINST");
return true;
}
for (uint i = 0; i < arg_count; i++) {item = args[i] = args[i]->real_item();
if (item->type() != Item::FIELD_ITEM ||
/* Cannot use FTS index with outer table field */
item->is_outer_reference()) {my_error(ER_WRONG_ARGUMENTS, MYF(0), "MATCH");
return true;
}
三、问题解决方案
通过以上代码解析后作如下批改,正确给 fixed
赋值,这样就能够保障每次 call sp
的时候如果遇到报错再次运行还会从新执行fix_fields
。
bool Item_func_match::fix_fields(THD *thd, Item **ref) {if (Item_func::fix_fields(thd, ref) || fix_func_arg(thd, &against) ||
!against->const_for_execution()) {
fixed = false; ==> 这里须要从新把 fixed 赋值为 false
thd->mark_used_columns = save_mark_used_columns;
my_error(ER_WRONG_ARGUMENTS, MYF(0), "AGAINST");
return true;
}
thd->mark_used_columns = save_mark_used_columns;
fixed = false; ==> 这里须要从新把 fixed 赋值为 false
for (uint i = 0; i < arg_count; i++) {item = args[i] = args[i]->real_item()->this_item();
if (item->type() != Item::FIELD_ITEM ||
/* Cannot use FTS index with outer table field */
item->is_outer_reference()) {my_error(ER_WRONG_ARGUMENTS, MYF(0), "MATCH");
return true;
}
两头省略
fixed = true; ==> 最初没有问题了再赋值为 true
return false;
当初从新执行 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 参数须要留神的点。
Enjoy GreatSQL :)
## 对于 GreatSQL
GreatSQL 是由万里数据库保护的 MySQL 分支,专一于晋升 MGR 可靠性及性能,反对 InnoDB 并行查问个性,是实用于金融级利用的 MySQL 分支版本。
相干链接:GreatSQL 社区 Gitee GitHub Bilibili
GreatSQL 社区:
社区博客有奖征稿详情:https://greatsql.cn/thread-100-1-1.html
技术交换群:
微信:扫码增加
GreatSQL 社区助手
微信好友,发送验证信息加群
。