MySQL/GreatSQL 游标重解析后条件下推core缺陷深度排查
一、问题发现
在一次开发中发现当执行需要条件下推cursor重新解析语句之后，会导致数据库core。看下面复现步骤，这里用的是mysql8.4.4的debug版本代码。
1、创建表和View
greatsql> CREATE TABLE tb1 (EMPLOYEE_ID int, FIRST_NAME VARCHAR2(20), LAST_NAME VARCHAR(25),
EMAIL VARCHAR2(25), PHONE_NUMBER VARCHAR2(20) DEFAULT NULL, HIRE_DATE DATE DEFAULT NULL,
JOB_ID VARCHAR2(10), SALARY NUMBER(8,2) DEFAULT 1000, COMMISSION_PCT DECIMAL(2,2) DEFAULT NULL,
MANAGER_ID float(6,0), DEPARTMENT_ID NUMBER(4,0),PRIMARY KEY(EMPLOYEE_ID)) ;
greatsql> INSERT INTO tb1 VALUES (145,'John','Russell','JRUSSEL','011.44.1344.429268','2020-3-1','SA_MAN',14000,0.4,100,80);
greatsql> CREATE TABLE tb2 (
EMPLOYEE_ID int PRIMARY KEY,
FIRST_NAME VARCHAR2(20) DEFAULT NULL,
LAST_NAME VARCHAR(25) DEFAULT NULL,
EMAIL VARCHAR2(25) DEFAULT NULL,
PHONE_NUMBER VARCHAR2(20) DEFAULT NULL,
HIRE_DATE DATE DEFAULT NULL,
JOB_ID VARCHAR2(10) DEFAULT NULL,
SALARY NUMBER(8,2) DEFAULT NULL,
COMMISSION_PCT DECIMAL(2,2) DEFAULT NULL,
MANAGER_ID DECIMAL(6,0) DEFAULT NULL,
DEPARTMENT_ID NUMBER(4,0) DEFAULT NULL
);
greatsql> INSERT INTO tb2 (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, JOB_ID, SALARY, DEPARTMENT_ID)
VALUES (145, 'John', 'Bonus Record', 'SA_MAN', 2000, 80);
greatsql> CREATE VIEW v_tb1 AS
SELECT * FROM ( SELECT * FROM tb1 UNION SELECT * FROM tb2) AS combined_tables
WHERE DEPARTMENT_ID = 80;
2、创建带有查询view的cursor的存储过程并执行sp
DROP PROCEDURE IF EXISTS `p1`;
DELIMITER $$
CREATE PROCEDURE `p1`(In p_dept_id integer)
BEGIN
declare cc cursor for SELECT EMPLOYEE_ID,DEPARTMENT_ID FROM v_tb1 WHERE department_id = p_dept_id;
open cc;
end $$
DELIMITER ;
-- 以下可以正常执行
greatsql> call p1(80);
-- 以下可以正常执行
greatsql> call p1(80);
3、改变view相关表的表结构并再次执行sp
greatsql> ALTER TABLE tb2 modify FIRST_NAME VARCHAR2(200);
-- 这里发现数据库core了
greatsql> CALL p1(80);
core的堆栈如下：
Thread 53 "connection" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140736954115648) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: 没有那个文件或目录.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140736954115648)
at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=140736954115648) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=140736954115648, signo=signo@entry=6)
at ./nptl/pthread_kill.c:89
#3 0x00007ffff7442476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff74287f3 in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff742871b in __assert_fail_base (
fmt=0x7ffff75dd130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
assertion=0x55555bf8d54a "!field_info.empty()",
file=0x55555bf8d1d8 "sql/sql_derived.cc",
line=565, function=<optimized out>) at ./assert/assert.c:94
#6 0x00007ffff7439e96 in __GI___assert_fail (assertion=0x55555bf8d54a "!field_info.empty()",
file=0x55555bf8d1d8 "sql/sql_derived.cc",
line=565, function=0x55555bf8d4a0 "copy_field_info(THD*, Item*, Item*)::<lambda(Item*)>")
at ./assert/assert.c:103
#7 0x00005555591f0641 in operator() (__closure=0x7fffe027c6a0, inner_item=0x7fff28c890d0)
at sql/sql_derived.cc:565
#8 0x00005555591f4d1b in Item::walk_helper_thunk<copy_field_info(THD*, Item*, Item*)::<lambda(Item*)> >(uchar *) (this=0x7fff28c890d0, arg=0x7fffe027c6a0 "\300\306'\340\377\177")
at sql/item.h:2559
#9 0x0000555558c4de9c in Item::walk (this=0x7fff28c890d0,
processor=(bool (Item::*)(Item * const, unsigned char *)) 0x5555591f4cf4 <Item::walk_helper_thunk<copy_field_info(THD*, Item*, Item*)::<lambda(Item*)> >(uchar *)>, walk=enum_walk::PREFIX,
arg=0x7fffe027c6a0 "\300\306'\340\377\177")
at sql/item.h:2552
#10 0x0000555558d34d0d in Item_func::walk (this=0x7fff28c89258,
processor=(bool (Item::*)(Item * const, unsigned char *)) 0x5555591f4cf4 <Item::walk_helper_thunk<copy_field_info(THD*, Item*, Item*)::<lambda(Item*)> >(uchar *)>, walk=enum_walk::PREFIX,
argument=0x7fffe027c6a0 "\300\306'\340\377\177")
at sql/item_func.cc:660
#11 0x0000555558cc05ad in Item_cond::walk (this=0x7fff28c88658,
processor=(bool (Item::*)(Item * const, unsigned char *)) 0x5555591f4cf4 <Item::walk_helper_thunk<copy_field_info(THD*, Item*, Item*)::<lambda(Item*)> >(uchar *)>, walk=enum_walk::PREFIX,
arg=0x7fffe027c6a0 "\300\306'\340\377\177")
at sql/item_cmpfunc.cc:6100
#12 0x00005555591f4d6c in WalkItem<copy_field_info(THD*, Item*, Item*)::<lambda(Item*)> >(Item *, enum_walk, struct {...} &&) (item=0x7fff28c88658, walk=enum_walk::PREFIX, functor=...)
at sql/item.h:3838
#13 0x00005555591f07ce in copy_field_info (thd=0x7fff28001060, orig_expr=0x7fff28c87878,
cloned_expr=0x7fff28c88658)
at sql/sql_derived.cc:563
#14 0x00005555591f0ec1 in Query_block::clone_expression (this=0x7fff28c58840,
thd=0x7fff28001060, item=0x7fff28c87878)
从函数堆栈和调用初步发现是view里面的派生表执行了条件下推，拷贝查询语句outer条件的时候发生了core。
二、问题调查过程
从上面现象思考2个问题：
1、前两次执行 call p1(80)的时候为何没有core，只有第3次的时候core了？
2、第3次core是什么原因？
观察上面第三次的call，可以发现操作之前执行了表的alter操作，这个操作影响了第三次的运行。
分析代码之前我们先看一下这个view在查询的时候执行的条件下推是什么：
CREATE VIEW v_tb1 AS
SELECT * FROM ( SELECT * FROM tb1 UNION SELECT * FROM tb2) AS combined_tables
WHERE DEPARTMENT_ID = 80;
这个查询用了派生表，优化器为了执行的时候提升效率会先对每张表进行条件过滤，最后再做union操作，这样可以减少表联合时候查询的行数。
于是上述例子在prepare的时候将会变成：
SELECT * FROM ( SELECT * FROM tb1 WHERE DEPARTMENT_ID = 8
UNION SELECT * FROM tb2 AS combined_tables WHERE DEPARTMENT_ID = 8);
可以看到条件原来是一个，这里做条件下推的时候就需要拷贝条件分别下推给两张表，于是就需要执行Query_block::clone_expression。
下面我们看一下core的地方copy_field_info相关代码调用流程。
Item *Query_block::clone_expression(THD *thd, Item *item) {
// 从源Item解析出目标Item
Item *cloned_item = parse_expression(thd, item, this);
if (cloned_item == nullptr) return nullptr;
if (item->item_name.is_set())
cloned_item->item_name.set(item->item_name.ptr(), item->item_name.length());
// 从源Item拷贝相关信息到目标Item
if (copy_field_info(thd, item, cloned_item)) return nullptr;
}
bool copy_field_info(THD *thd, Item *orig_expr, Item *cloned_expr) {
// 以下遍历orig_expr，从orig_expr参数中抽取出FIELD_ITEM并且加入到field_info，本次例子抽取出的field是2个department_id
if (WalkItem(orig_expr, enum_walk::PREFIX,
[&field_info, &depended_from, &context](Item *inner_item) {
if (inner_item->type() == Item::FIELD_ITEM) {
Item_field *field = down_cast<Item_field *>(inner_item);
if (field_info.push_back(
Field_info(context, field->table_ref, depended_from,
field->cached_table, field->field)))
return true;
}
return false;
}))
return true;
// Copy the information to the fields in the cloned expression.
// 以下遍历cloned_expr，把从源表达式抽取出来的field信息拷贝到目标表达式cloned_expr对应的field。很显然，源和目标的field数量肯定是一样的。
WalkItem(cloned_expr, enum_walk::PREFIX, [&field_info](Item *inner_item) {
if (inner_item->type() == Item::FIELD_ITEM) {
// 这里要从源拷贝field信息，因此必须保证当前field_info还有剩余field信息，如果为空了说明源和目标的field数量不一致就有问题了。
// 本次core的地方在这里，就说明源和目标表达式的field数量不一致，因此需要调查为什么存在不一致。
assert(!field_info.empty());
Item_field *field = down_cast<Item_field *>(inner_item);
field->context = field_info[0].m_field_context;
field->table_ref = field_info[0].m_table_ref;
field->depended_from = field_info[0].m_depended_from;
field->cached_table = field_info[0].m_cached_table;
field->field = field_info[0].m_field;
field_info.pop_front();
}
return false;
});
}
分析copy_field_info函数执行时候拆解出来的具体Item元素，用下表显示：
| 执行次数 | orig_expr条件 | 条件包含的参数 | 参数包含的Item元素 |
|---|---|---|---|
| 第一次 | Item_cond_and | Item_func_eq (DEPARTMENT_ID = 80) Item_func_eq (DEPARTMENT_ID = p_dept_id) | DEPARTMENT_ID = 80 分别是Item_field和Item_int DEPARTMENT_ID = p_dept_id 分别是Item_field和Item_splocal |
| 第三次 | Item_cond_and | Item_func_eq (DEPARTMENT_ID = 80) Item_func_eq (DEPARTMENT_ID = p_dept_id) | DEPARTMENT_ID = 80 分别是Item_field和Item_int DEPARTMENT_ID = p_dept_id 分别是Item_field和Item_field(问题点) |
通过对比表可以很清楚的看到有问题的第三次的最后一个Item变为了Item_field，而正确执行的第一次是解析为Item_splocal。就是这个field数量差异导致了core。
第三次执行的时候为什么Item会跟第一次不一样呢？我们注意到第三次之前做了alter table的操作，这个操作导致表版本更新，于是触发了cursor的查询语句的reprepare操作。对应的代码如下：
bool sp_lex_instr::validate_lex_and_execute_core(THD *thd, uint *nextp,
bool open_tables) {
while (true) {
DBUG_EXECUTE_IF("simulate_bug18831513", { invalidate(); });
// 如果表版本有更新，就需要重新parse这个语句对应的查询语句
if (is_invalid() ||
((m_lex->has_udf()) &&
!m_first_execution)) {
free_lex();
LEX *lex = parse_expr(thd, thd->sp_runtime_ctx->sp);
if (!lex) return true;
set_lex(lex, true);
m_first_execution = true;
}
}
上面代码执行parse_expr的时候，在下面函数重新解析p_dept_id这个参数。可以发现就是因为lex->find_variable没有找到对应的参数最后一个元素才变为Item_field
bool PTI_simple_ident_ident::itemize(Parse_context *pc, Item **res) {
if (!is_with_func_ident &&
// 如果lex找到用户定义的参数就解析为Item_splocal
(spv = lex->find_variable(ident.str, ident.length, &rh))) {
*res = create_item_for_sp_var(
thd, ident, rh, spv, sp->m_parser_data.get_current_stmt_start_ptr(),
raw.start, raw.end);
lex->safe_to_cache_query = false;
} else
// 如果lex没找到用户定义的参数就解析为Item_field
*res = new (pc->mem_root) Item_field(POS(), NullS, NullS, ident.str);
}
GDB看一下find_variable为什么没有找到这个变量，打印下面spc的值发现是nullptr，因此发现是reparse查询语句以后lex->get_sp_current_parsing_ctx()变为空了，所以导致第三次没有找到对应的变量。
LEX::find_variable (this=0x7fffe047fc00, name=0x7fff30d9a918 "p_dept_id", name_len=9, ctx=0x7fffe047b7b0, rh=0x7fffe047b7f8, also_find_udt=true) at /home/wuyy/greatdb/gitmerge/percona-server/sql/sql_lex.cc:5955
5955 sp_pcontext *spc = get_sp_current_parsing_ctx();
(gdb) n
5957 if (spc && ((spv = spc->find_variable(name, name_len, false)) ||
(gdb) s
5967 sp_package *pkg = sphead ? sphead->get_package() : nullptr;
(gdb) p spc
$16 = (sp_pcontext *) 0x0
三、问题解决
从上面分析结论，我们发现是set_lex的时候没有把旧的sp_pcontext和sp_head值赋给新的lex，因此在set_lex的时候进行赋值就可以解决问题。
void sp_lex_instr::set_lex(LEX *lex, bool is_lex_owner) {
free_lex();
m_lex = lex;
m_is_lex_owner = is_lex_owner;
m_lex_query_tables_own_last = nullptr;
if (m_lex) {
m_lex->sp_lex_in_use = true;
// 添加下面的赋值代码，判断当前lex有变化的时候进行赋值
// It needs m_parsing_ctx and sphead in parse_expression to parse expr.
if (!m_first_execution) {
m_lex->set_sp_current_parsing_ctx(m_parsing_ctx);
m_lex->sphead = current_thd->sp_runtime_ctx->sp;
}
}
}
void sp_lex_instr::free_lex() {
if (!m_is_lex_owner || !m_lex) return;
/* Prevent endless recursion. */
m_lex->sphead = nullptr;
// 释放的时候需要注意不能把旧的sp_pcontext删了，因此需要先置空
if (!m_first_execution) m_lex->set_sp_current_parsing_ctx(nullptr);
lex_end(m_lex);
destroy(m_lex->result);
}
编译以后再次运行call p1，问题解决。
greatdb> alter table tb2 modify FIRST_NAME VARCHAR2(200);
greatdb> call p1(80);
Query OK, 0 rows affected (0.02 sec)
四、问题总结
针对 MySQL 8.4.4 调试版环境下，视图+游标联动场景触发数据库Core的问题做了完整排查与修复：修改视图关联表结构后，会触发游标语句重新解析，因重解析时存储过程上下文丢失，导致输入参数解析异常、字段数量不匹配，最终触发断言崩溃。
解决方案为补全语句重解析时的存储过程上下文传递逻辑，修复set_lex函数的上下文赋值环节即可解决问题。
日常开发需注意：涉及游标、嵌套视图的存储过程，要规避频繁变更关联表结构，内核开发需严控重解析场景的上下文生命周期，避免上下文丢失引发同类崩溃。
通过以上分析我们可以发现，cursor的使用因为跟查询语句密切相关，因此比别的存储过程的语句复杂很多，涉及的知识面也更广，想要解析相关问题需要从优化器和存储过程的执行原理出发分析才能找到问题点，需要扎实的数据库知识储备。平时开发需要注重积累，才能在发现问题的时候快速定位问题和解决问题。
173
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
