MySQL的match函數(shù)在sp中使用BUG解決分析
一、問題發(fā)現(xiàn)
在一次開發(fā)中在sp中使用MySQL PREPARE以后，使用match AGAINST語句作為prepare stmt的參數(shù)后，發(fā)現(xiàn)執(zhí)行第二遍call會導(dǎo)致數(shù)據(jù)庫crash，于是開始動手調(diào)查問題發(fā)生的原因。
注：本次使用的 MySQL 數(shù)據(jù)庫版本為最新的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 ;
執(zhí)行結(jié)果：
mysql> call p1;
ERROR 1210 (HY000): Incorrect arguments to MATCH
mysql> call p1; 這里發(fā)現(xiàn)代碼crash了
ERROR 2013 (HY000): Lost connection to MySQL server during query二、問題調(diào)查過程
1、首先查看錯誤堆棧信息，可以看到Item_func_match::val_real函數(shù)的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) 這里導(dǎo)致的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:862、要想獲取sp參數(shù)的實際item，應(yīng)該調(diào)用this_item()方法，但是也許作者本來就不想讓match支持sp參數(shù)，因此這里的寫法是對的。但是本來代碼不應(yīng)該運行到這里，因為本來應(yīng)該直接報錯。
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、接著繼續(xù)調(diào)查，查看第一次報錯的地方的代碼，找到Item_func_match::fix_fields，看到了第一次報錯的地方的代碼item->type() != Item::FIELD_ITEM，因此代碼運行應(yīng)該在這里報錯。但是為何第二次執(zhí)行會運行到Item_func_match::val_real而不是在Item_func_match::fix_fields就直接報錯返回呢？仔細(xì)查看下面的代碼，發(fā)現(xiàn)下面的代碼有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執(zhí)行完后使fixed=true
但是如果后面有任何報錯的地方導(dǎo)致返回的話，這個值沒有修改回false
會導(dǎo)致第二次call sp不會再次執(zhí)行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的時候如果遇到報錯再次運行還會重新執(zhí)行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;現(xiàn)在重新執(zhí)行call sp，沒有問題了。
mysql> call p1; ERROR 1210 (HY000): Incorrect arguments to MATCH mysql> call p1; ERROR 1210 (HY000): Incorrect arguments to MATCH
四、問題總結(jié)
本次只是解決了match的fix_fields問題，但是如果想讓 match 支持 sp 的參數(shù)，即Item_splocal的參數(shù)的話，代碼里面還要做相應(yīng)修改，包括set @bb := match(a,b) AGAINST ('collections'); 這里面生成的Item_func_match會在這句執(zhí)行完以后被 cleanup 掉，等到下一句 prepare 想再次使用它的時候會因為找不到該item發(fā)生問題，這個是重構(gòu) match函數(shù)支持 sp 參數(shù)需要注意的點。
Enjoy GreatSQL :)
## 關(guān)于 GreatSQL
GreatSQL是由萬里數(shù)據(jù)庫維護的MySQL分支，專注于提升MGR可靠性及性能，支持InnoDB并行查詢特性，是適用于金融級應(yīng)用的MySQL分支版本。
相關(guān)鏈接：
以上就是MySQL的match函數(shù)在sp中使用BUG解決分析的詳細(xì)內(nèi)容，更多關(guān)于MySQL match函數(shù)的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
最近在項目中使用 mybatis 寫 SQL 使用了 where 1=1 來簡化多條件拼接的寫法,案例如下,借此聊聊多條件拼接的常見的一些寫法以及 where 1=1 是否存在性能影響,需要的朋友可以參考下2024-02-02
這篇文章主要介紹了MySQL的WHERE語句中BETWEEN與IN的使用教程,是MySQL入門學(xué)習(xí)中的基礎(chǔ)知識,需要的朋友可以參考下2015-12-12
mysql ERROR 1045 (28000)問題的解決方法
這篇文章主要介紹了mysql ERROR 1045 (28000)問題的解決方法，文中步驟介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們可以參考一下2019-10-10
在使用MySQL時,時區(qū)設(shè)置容易引發(fā)一些錯誤,本文將介紹MySQL時區(qū)問題可能引發(fā)的錯誤,并提供一些解決方案,具有一定的參考價值,感興趣的可以了解一下2024-07-07
這篇文章主要介紹了mysql命令行如何操作，還為大家分享了mysql添加環(huán)境變量的方法，感興趣的小伙伴們可以參考一下2015-11-11
這篇文章主要介紹了InnoDB隔離模式的使用對MySQL性能造成的影響,作為基于MySQL的最出名的數(shù)據(jù)庫,InnoDB相關(guān)的性能問題一直是DBA關(guān)注的熱點,需要的朋友可以參考下2015-06-06
基于mysql+mycat搭建穩(wěn)定高可用集群負(fù)載均衡主備復(fù)制讀寫分離操作
這篇文章主要介紹了基于mysql+mycat搭建穩(wěn)定高可用集群負(fù)載均衡主備復(fù)制讀寫分離操作,需要的朋友可以參考下2018-09-09
這篇文章主要介紹了mysql按照時間分組查詢的語句,非常實用，sql語句簡單易懂，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2021-10-10
MySql 存儲引擎和索引相關(guān)知識總結(jié)
這篇文章主要介紹了MySql 存儲引擎和索引相關(guān)知識總結(jié)，文中講解非常細(xì)致，代碼幫助大家更好的理解和學(xué)習(xí)，感興趣的朋友可以了解下2020-06-06
阿里云 Centos7.3安裝mysql5.7.18 rpm安裝教程
這篇文章主要介紹了阿里云 Centos7.3安裝mysql5.7.18 rpm安裝教程,需要的朋友可以參考下2017-06-06