一、問題發現

在一次開發中在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 參數需要注意的點。

審核編輯：劉清