乐趣区

关于数据库:MySQL中sp运行check表版本更新流程解析

jiezi
  • GreatSQL 社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。
  • GreatSQL 是 MySQL 的国产分支版本，应用上与 MySQL 统一。
  • 作者：wuyy
  • 文章起源：GreatSQL 社区原创

目录

  • MySQL 的 sp 运行 SQL 语句两个步骤介绍
  • 代码跟踪
  • 常识利用
  • 总结

一、MySQL 的 sp 运行 sql 语句两个步骤介绍

MySQL 的 sp 运行 SQL 语句须要执行 2 个步骤：prepare 和 execute。第一次执行的时候先执行 prepare，进行相干语句 parse、itemize、fix_fields 等操作，而后才开始进行 execute 操作。等第二次再执行该 sp 的时候就间接运行 execute 而不须要再次进行反复的 prepare 操作，这样能够节俭 sp 运行时候反复 prepare 的开销。然而，对于表操作就有一个问题产生，那就是如果执行第二遍的时候表的构造产生扭转了，那么不进行 reprepare 而间接 execute 是会产生谬误的。因而，本文章的目标在于寻找 sp 屡次运行时候如何确认表版本更新并进行正确的操作。

先看上面的例子：CREATE TABLE t1 (a INT, b VARCHAR(10));
INSERT INTO t1 VALUES (1,'11');
INSERT INTO t1 VALUES (2,'21');
MySQL> select * from t1;
+------+------+
| a    | b    |
+------+------+
|    1 | 11   |
|    2 | 21   |
+------+------+
2 rows in set (0.01 sec)
DELIMITER $$
CREATE PROCEDURE p1()
BEGIN
update t1 set b='aa' where a=1;
END $$
DELIMITER ;
MySQL> call p1; #这里第一次操作，因而会先执行 update 这句 SQL 的 prepare 再进行 execute。Query OK, 1 row affected (0.05 sec)

MySQL> select * from t1;
+------+------+
| a    | b    |
+------+------+
|    1 | aa   |
|    2 | 21   |
+------+------+
2 rows in set (0.01 sec)
MySQL> call p1; #这里第二次操作，间接执行 update 这句 SQL 的 execute。Query OK, 0 rows affected (13.78 sec)

#接着咱们执行表构造的更新。MySQL> alter table t1 add i int;
Query OK, 0 rows affected (0.41 sec)
Records: 0  Duplicates: 0  Warnings: 0

#而后再次执行 sp，就会发现这次执行了这句 SQL 的 prepare 再进行 execute。MySQL> call p1;
Query OK, 0 rows affected (34.24 sec)

二、代码跟踪

当初跟踪一下这个 sp 看看下面在哪里 check 表版本并且能正确执行 reprepare 的。

# 首先看一下这个 sp 波及的 instr。MySQL> show procedure code p1;
+-----+---------------------------------------+
| Pos | Instruction                           |
+-----+---------------------------------------+
|   0 | stmt "update t1 set b='aa'where a=1" |
+-----+---------------------------------------+
1 row in set (0.01 sec)
能够看到这个 sp 只波及了 sp_instr_stmt::execute 的运行，因而跟踪一下代码找到 sp_lex_instr::validate_lex_and_execute_core，能够发现这个函数外面有一个有限 while 循环，如果发现 is_invalid()的话就从新执行 parse 动作，如果！is_invalid()就间接执行 exec_core，这个跟下面的运行步骤就对的上了。然而表构造变更后在哪里被断定为 rc=true 的呢，那就从 reset_lex_and_exec_core 这个函数持续跟踪上来。bool sp_lex_instr::validate_lex_and_execute_core(THD *thd, uint *nextp,
                                                 bool open_tables) {while (true) {if (is_invalid() || (m_lex->has_udf() && !m_first_execution)) {LEX *lex = parse_expr(thd, thd->sp_runtime_ctx->sp);
    }
    bool rc = reset_lex_and_exec_core(thd, nextp, open_tables);
    if (!rc) return false;
    thd->clear_error();
    invalidate();}
}
#跟踪代码发现有一个 check_and_update_table_version 函数是用来 check 表版本是否统一的
#打印堆栈看一下代码调用过程：Thread 51 "mysqld" hit Breakpoint 6, check_and_update_table_version (thd=0x7fff70001060, tables=0x7fff702c4e20, 
    table_share=0x7fff70297640) at /mysql/sql/sql_base.cc:3722
3722   if (!tables->is_table_ref_id_equal(table_share)) {(gdb) bt
#0  check_and_update_table_version (thd=0x7fff70001060, tables=0x7fff702c4e20, table_share=0x7fff70297640)
    at /mysql/sql/sql_base.cc:3722
#1  0x0000000003340f71 in open_and_process_table (thd=0x7fff70001060, lex=0x7fff702c2650, tables=0x7fff702c4e20, 
    counter=0x7fff702c26a8, prelocking_strategy=0x7fffec2e7478, has_prelocking_list=false, ot_ctx=0x7fffec2e7368)
    at /MySQL/sql/sql_base.cc:5223
#2  0x000000000333f788 in open_tables (thd=0x7fff70001060, start=0x7fffec2e7488, counter=0x7fff702c26a8, flags=0, 
    prelocking_strategy=0x7fffec2e7478) at /mysql/sql/sql_base.cc:5968
#3  0x0000000003343c96 in open_tables_for_query (thd=0x7fff70001060, tables=0x7fff702c4e20, flags=0)
    at /MySQL/sql/sql_base.cc:6958
#4  0x0000000003514334 in Sql_cmd_dml::execute (this=0x7fff702c6138, thd=0x7fff70001060)
    at /MySQL/sql/sql_select.cc:543
#5  0x0000000003475097 in mysql_execute_command (thd=0x7fff70001060, first_level=false)
    at /MySQL/sql/sql_parse.cc:3832
#6  0x00000000033075c6 in sp_instr_stmt::exec_core (this=0x7fff70249a80, thd=0x7fff70001060, nextp=0x7fffec2eac38)
    at /MySQL/sql/sp_instr.cc:1008
#7  0x00000000033052ed in sp_lex_instr::reset_lex_and_exec_core (this=0x7fff70249a80, thd=0x7fff70001060, 
    nextp=0x7fffec2eac38, open_tables=false) at /mysql/sql/sp_instr.cc:457
#8  0x00000000033060a4 in sp_lex_instr::validate_lex_and_execute_core (this=0x7fff70249a80, thd=0x7fff70001060, 
    nextp=0x7fffec2eac38, open_tables=false) at /mysql/sql/sp_instr.cc:741
#9  0x0000000003306748 in sp_instr_stmt::execute (this=0x7fff70249a80, thd=0x7fff70001060, nextp=0x7fffec2eac38)
    at /MySQL/sql/sp_instr.cc:925
#10 0x00000000032f4d74 in sp_head::execute (this=0x7fff7018e7a0, thd=0x7fff70001060, merge_da_on_success=true)
    at /MySQL/sql/sp_head.cc:2272
#11 0x00000000032f80e1 in sp_head::execute_procedure (this=0x7fff7018e7a0, thd=0x7fff70001060, args=0x0)
    at /MySQL/sql/sp_head.cc:2977
#能够发现 open_tables 函数调用了这个函数，这个函数调用了 ask_to_reprepare，#在 sp 运行中这个 ask_to_reprepare 返回的是 true。因而这里就解开了之前的问题，#为何表版本更新了会 return true 而后从新进行 parse 操作。static bool check_and_update_table_version(THD *thd, TABLE_LIST *tables,
                                           TABLE_SHARE *table_share) {if (!tables->is_table_ref_id_equal(table_share)) {
    /*
      Version of the table share is different from the
      previous execution of the prepared statement, and it is
      unacceptable for this SQLCOM.
    */
    if (ask_to_reprepare(thd)) return true;
    /* Always maintain the latest version and type */
    tables->set_table_ref_id(table_share);
  }
  return false;
}

三、常识利用

如果想开发一种动静表类型，须要每次执行 sp 都从新 parse 这个表，那就能够借用这个 ask_to_reprepare 函数来保障屡次执行 sp 的时候都会进行从新 reprepare。

四、总结

在 MySQL 的 sp 操作中波及表操作的 sql 语句肯定会执行 check_and_update_table_version 这个函数，每次会依据这个函数的后果来确定要不要从新 parse 该 sql 语句，如果没有版本扭转就间接进行 execute 操作，如果有扭转就从新 parse，先 prepare 再 execute，这样能够保障每次执行 sp 的 SQL 语句的时候表构造肯定是最新的。

Enjoy GreatSQL :)

## 对于 GreatSQL

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

相干链接：GreatSQL 社区 Gitee GitHub Bilibili

GreatSQL 社区：

社区博客有奖征稿详情：https://greatsql.cn/thread-10…

技术交换群：

微信：扫码增加 GreatSQL 社区助手 微信好友，发送验证信息 加群。

退出移动版