时间:2023-10-29来源:系统城装机大师作者:佚名
在一次开发中在sp中使用MySQL PREPARE
以后,使用match AGAINST
语句作为prepare stmt
的参数后,发现执行第二遍call会导致数据库crash,于是开始动手调查问题发生的原因。
注:本次使用的 MySQL 数据库版本为最新的debug版本。
SQL语句示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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
。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
#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参数,因此这里的写法是对的。但是本来代码不应该运行到这里,因为本来应该直接报错。
1 2 3 4 5 6 |
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个地方有错误。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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
。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
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,没有问题了。
1 2 3 4 |
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
以上就是MySQL的match函数在sp中使用BUG解决分析的详细内容
2023-10-30
windows上的mysql服务突然消失提示10061 Unkonwn error问题及解决方案2023-10-30
MySQL非常重要的日志bin log详解2023-10-30
详解MySQL事务日志redo log一、单表查询 1、排序 2、聚合函数 3、分组 4、limit 二、SQL约束 1、主键约束 2、非空约束 3、唯一约束 4、外键约束 5、默认值 三、多表查询 1、内连接 1)隐式内连接: 2)显式内连接: 2、外连接 1)左外连接 2)右外连接 四...
2023-10-30
Mysql删除表重复数据 表里存在唯一主键 没有主键时删除重复数据 Mysql删除表中重复数据并保留一条 准备一张表 用的是mysql8 大家自行更改 创建表并添加四条相同的数据...
2023-10-30