本篇文章记录的是遇到一个未知错误的排查过程，由于本人水平有限，如有描述不正确的欢迎指正。

问题描述

开发报错
MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？ - 图1

  1. MySQL error code 1615 (ER_NEED_REPREPARE): Prepared statement needs to be re-prepared

排查过程

咋一看，没见过这个错误啊，用大腿想了下这个应该是php程序为了防止SQL注入用的prepare执行的。赶紧官方bug搜了一下，一通操作以后路由到了如下地址：https://dev.mysql.com/doc/refman/5.5/en/statement-repreparation.html

简单看了一下，大概意思就是after prepare before execute的阶段，对应的表进行了DDL或者FLUSH TABLES以后table definition cache里面的metadata信息发生了改变，需要reprepare

接着我搜了一下源码，关键字re-prepare，然后我看到官方test套件里有相关的测试
MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？ - 图2

可以看到对应的worklog为4166
拿到worklog id以后，我赶紧去官方的work log下搜，在High Level Architecture标签下，我注意到了下面几行

  1. Prepared_statement::execute_loop() -- try to execute
  2. a statement, reprepare in case of validation error, and try
  3. again until MAX_REPREPARE_ATTEMPTS has been reached.
  4. mysql_{sql_}stmt_execute() are changed to invoke this
  5. method instead of plain execute().
  7. Prepared_statement::reprepare() -- reprepare a prepared
  8. statement, called from execute_loop() in case of ER_NEED_REPREPARE
  9. error.

找到了对应的入口函数：
Prepared_statement::execute_loop()
主要抛出错误位置如下：

  1.   if ((sql_command_flags[lex->sql_command] & CF_REEXECUTION_FRAGILE) &&
  2.       error && !thd->is_fatal_error && !thd->killed &&
  3.       // reprepare观察者发现invalidated，尝试MAX_REPREPARE_ATTEMPTS后报错ER_NEED_REPREPARE
  4.       reprepare_observer.is_invalidated() &&
  5.       reprepare_attempt++ < MAX_REPREPARE_ATTEMPTS)
  6.   {
  7.     DBUG_ASSERT(thd->get_stmt_da()->mysql_errno() == ER_NEED_REPREPARE);
  8.     thd->clear_error();
  10.     error= reprepare();
  12.     if (! error)                                /* Success */
  13.       goto reexecute;
  14.   }

注意一下观察者Reprepare_observer定义

  1. /**
  2. Reprepare_observer观察者是用来观察某个表从上一次执行后的版本变化  
  3. 这里的"table"可以是MySQL表、临时表、视图或者information schema的表
  5. 当我们执行prepared SQL进行打开表并加锁的时候，必须要确认表没有发生改变(DML除外)。因为如果从上次prepare后表发生了改变，那么解析树可能就失效了，例如它可能包含了基于表metadata的优化。
  7.   @sa check_and_update_table_version() 获取版本跟踪算法
  8. */
  10. class Reprepare_observer
  11. {
  12. public:
  13.   /**
  14.   检查meatadata是否有变化
  15.   */
  16.   bool report_error(THD *thd);
  17.   bool is_invalidated() const { return m_invalidated; }
  18.   void reset_reprepare_observer() { m_invalidated= FALSE; }
  19. private:
  20.   bool m_invalidated;
  21. };

注释里写的非常明显，

  1. check_and_update_table_version() for details of the
  2.   version tracking algorithm

所以我们主要目光聚集在函数check_and_update_table_version，其定义如下：

  1. /**
  2. 这里需要比较table definition cache中的元数据版本和之前prepare生成的parse tree中的node进行版本对比
  4. */
  6. static bool
  7. check_and_update_table_version(THD *thd,
  8.                                TABLE_LIST *tables, TABLE_SHARE *table_share)
  9. {
  10.    // 如果table_id != prepare时的table id，抛出错误，如果是prepare时期，虽然也不匹配，但是这个时候并没有观察者，也就不会抛出错误，但是到execute时，已经有了观察者，这个时候不匹配的话，就会抛出错误了
  11.   if (! tables->is_table_ref_id_equal(table_share))
  12.   {
  13.     Reprepare_observer *reprepare_observer= thd->get_reprepare_observer();
  15.     if (reprepare_observer &&
  16.         reprepare_observer->report_error(thd))
  17.     {
  18.       /*
  19.         版本不匹配，抛出错误，返回TRUE
  20.       */
  21.       DBUG_ASSERT(thd->is_error());
  22.       return TRUE;
  23.     }
  24.     /* 根据table definition cache中的table id更新，总是维护最新的 */
  25.     tables->set_table_ref_id(table_share);
  26.   }
  28.   DBUG_EXECUTE_IF("reprepare_each_statement", return inject_reprepare(thd););
  29.   return FALSE;
  30. }

从函数check_and_update_table_version中可以看出来，在prepare和execute之间这段时间内，如果table_ref_id（这里的table id其实就是binlog里面的table map event里面的table id，是可以变化的）如果发生了变化，那么需要reprepare。其中还有一点需要注意的是，在prepare之后，会释放对应的MDL锁，所以这个时候是可以进行DDL操作的。那么问题来了，什么情况下，这个table id会发生变化呢？

  1. DDL(包括ALTER/RENAME/TRUNCATE等)
  2. FLUSH TABLES显式地将表定义刷出缓存
  3. TABLE_DEFINITION_CACHE太小，导致对应的表定义缓存被刷出

以上根据自己的经验不完全统计。。。

关于table id

MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？ - 图3

用户查询一个表的数据时，首先会构造根据库名、表名等信息构造hash key，然后从table_def_cache这个hash map中找是否有对应表的缓存，如果存在的话，实例化TABLE_SHARE结构体为TABLE，跟用户交互。如果不存在的话，那么会获取库名、表名等信息存入TABLE_SHARE结构体，在这里生成table_id。
生成table_id的函数如下：

  1. static Table_id last_table_id;
  3. void assign_new_table_id(TABLE_SHARE *share)
  4. {
  6.   DBUG_ENTER("assign_new_table_id");
  8.   /* Preconditions */
  9.   DBUG_ASSERT(share != NULL);
  10.   mysql_mutex_assert_owner(&LOCK_open);
  12.   DBUG_EXECUTE_IF("dbug_table_map_id_500", last_table_id= 500;);
  13.   DBUG_EXECUTE_IF("dbug_table_map_id_4B_UINT_MAX+501",
  14.                   last_table_id= 501ULL + UINT_MAX;);
  15.   DBUG_EXECUTE_IF("dbug_table_map_id_6B_UINT_MAX",
  16.                   last_table_id= (~0ULL >> 16););
  18.   share->table_map_id= last_table_id++;
  19.   DBUG_PRINT("info", ("table_id=%llu", share->table_map_id.id()));
  21.   DBUG_VOID_RETURN;
  22. }

过程模拟

本模拟案例由重庆八怪提供，非常感谢

session 1 session2
prepare xxx
MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？ - 图4
MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？ - 图5

调试过程：
MySQL DBA如何"土土"地利用源码解决没有遇到过的错误？ - 图6

这里我们只需要将reprepare_attempt < MAX_REPREPARE_ATTEMPTS 改为不满足条件即可因此
修改reprepare_attempt变量为3则，reprepare_attempt < MAX_REPREPARE_ATTEMPTS 返回false
进入报错流程而不会重新加载table

总结：

这个问题的本质就是table share 在 prepare 和 execute 之间被重新加载了多次
伪代码逻辑如下:

  1. prepare:reprepare_attempt=0 MAX_REPREPARE_ATTEMPTS=3 :
  2. execute:
  3.      如果table table被重置过了那么 reprepare_attempt +=1
  4.      loop：
  5.         重新准备 reprepare
  6.         再次 execute
  7.         如果table table被重置过了继续循环 reprepare_attempt +=1,如果reprepare_attempt>=MAX_REPREPARE_ATTEMPTS 这报错
  8.         否则正常退出循环，正常执行
  9.      end loop

实际会进行3次执行尝试，如果都失败就会报错。因此自己模拟的话还是比较难模拟的，除非直接gdb set 变量或者在线上高压力下才可能出现。

为解决上述的1615问题，可以通过以下办法：

  1. 增加table_definition_cache，方式表定义被刷出缓存
  2. 增加MAX_REPREPARE_ATTEMPTS次数，但是这个属于hard code，没法通过参数修改
  3. 没事别FLUSH TABLES…(如备份，包括extrabackup和mysqldump获取一致性位点都会做FTWRL，因此建议专门的从库做备份)