這里我們主要分析一下簡單類型語句show engine innodb status這個語句是如何執(zhí)行的。

詞法分析

主要是通過DFA有限狀態(tài)機(jī)進(jìn)行詞素分析，并且返回相關(guān)的token和token對應(yīng)的值，供語法分析階段使用。而語句里面實(shí)際上主要是這4個詞素show/engine/innodb/status

token（終結(jié)符包含）SHOW/ENGINE_SYM /STATUS_SYM，在符號表中包含：

• {SYM("SHOW", SHOW)},
• {SYM("ENGINE", ENGINE_SYM)},
• {SYM("STATUS", STATUS_SYM)},

而詞素innodb為標(biāo)識符IDENT。其次可以查看Lex_hash::get_hash_symbol函數(shù)觀察語法分析中如何查閱的符號表返回token的。及如下：

#0  Lex_hash::get_hash_symbol (this=0x842a410 <Lex_hash::sql_keywords>, s=0xad36f88 "show engine innodb status", 
    len=4) at /newdata/mysql-8.0.23/sql/sql_lex_hash.cc:75
#1  0x00000000037b144b in find_keyword (lip=0x7fffbc564a58, len=4, function=false)
    at /newdata/mysql-8.0.23/sql/sql_lex.cc:875
#2  0x00000000037b2b80 in lex_one_token (yylval=0x7fffbc562ef0, thd=0xad326c0)
    at /newdata/mysql-8.0.23/sql/sql_lex.cc:1480

語法分析：

然后就是進(jìn)入語法分析，這里用到是yacc/bsion，語法分析主要是采用LALR，最右推導(dǎo)，自底向上通過終結(jié)符(token)不斷的移入/歸約，進(jìn)行語法的驗(yàn)證，最終生成AST抽象語法樹，那么重點(diǎn)就是找到相應(yīng)的規(guī)則和action，其匹配規(guī)則流程如下：

start_entry
 sql_statement
 simple_statement_or_begin
 simple_statement
 show_engine_status_stmt:
          SHOW ENGINE_SYM engine_or_all STATUS_SYM
          {
            $$ = NEW_PTN PT_show_engine_status(@$, $3);
          }
        ;

最終規(guī)則show_engine_status_stmt的action主要是構(gòu)造PT_show_engine_status類，其他已經(jīng)是終結(jié)符，而engine_or_all為非終結(jié)符，繼續(xù)匹配規(guī)則最后為IDENT為標(biāo)識符直接輸入到$3，我們這里就是字符串innodb

• PT_show_engine_status <-繼承 PT_show_engine_base <-繼承PT_show_base <-繼承 Parse_tree_root

這個節(jié)點(diǎn)就是語法樹的根節(jié)點(diǎn)，沒有其他節(jié)點(diǎn)了，因?yàn)檫@屬于簡單的命令。其中對于每種類型的語句通常有一個對應(yīng)的類型的根節(jié)點(diǎn)，都繼承來自Parse_tree_root類然后對語法樹進(jìn)行實(shí)例化，也就是和具體執(zhí)行函數(shù)關(guān)聯(lián)，其中PT_show_engine_status包含私有成員，

Sql_cmd_show_engine_status m_sql_cmd

而其繼承關(guān)系如下：

• Sql_cmd_show_engine_status <-繼承 Sql_cmd_show_noplan <-繼承 Sql_cmd_show <-繼承 Sql_cmd_select <-繼承 Sql_cmd_dml <-繼承Sql_cmd

在實(shí)例化的時候PT_show_engine_status::make_cmd并沒有太多的動作，檢查一下引擎是否存在，然后直接return &m_sql_cmd,返回個LEX::m_sql_cmd存放在thd->lex中，也就是把Sql_cmd_show_engine_status的對象放到thd->lex，那么Sql_cmd類實(shí)際上就是解析器和執(zhí)行器之間的橋梁。

執(zhí)行階段：

執(zhí)行階段由調(diào)用從LEX中獲取m_sql_cmd，調(diào)用執(zhí)行函數(shù)執(zhí)行，也就是Sql_cmd的純虛函數(shù)virtual bool execute(THD *thd) = 0;

由于Sql_cmd_show_noplan進(jìn)行了重寫，調(diào)用的是Sql_cmd_show_noplan的execute,然后由于Sql_cmd_show_noplan的execute調(diào)用Sql_cmd_show_engine_status::execute_inner,調(diào)入了ha_show_status，開始掃描引擎打印信息，當(dāng)然最終會調(diào)入innobase_show_status函數(shù)進(jìn)行打印innodb的各種信息，如下：

#3  0x0000000004f3ba5b in innodb_show_status (hton=0xaa45010, thd=0xad326c0, 
   stat_print=0x3b7e3d0 <stat_print(THD*, char const*, size_t, char const*, size_t, char const*, size_t)>)
   at /newdata/mysql-8.0.23/storage/innobase/handler/ha_innodb.cc:18275
#4  0x0000000004f3c818 in innobase_show_status (hton=0xaa45010, thd=0xad326c0, 
   stat_print=0x3b7e3d0 <stat_print(THD*, char const*, size_t, char const*, size_t, char const*, size_t)>, 
   stat_type=HA_ENGINE_STATUS) at /newdata/mysql-8.0.23/storage/innobase/handler/ha_innodb.cc:18660
#5  0x0000000003b7e776 in ha_show_status (thd=0xad326c0, db_type=0xaa45010, stat=HA_ENGINE_STATUS)
   at /newdata/mysql-8.0.23/sql/handler.cc:7577
#6  0x0000000003889646 in Sql_cmd_show_engine_status::execute_inner (this=0xb498fd8, thd=0xad326c0)
   at /newdata/mysql-8.0.23/sql/sql_show.cc:467
#7  0x0000000003899a5a in Sql_cmd_show_noplan::execute (this=0xb498fd8, thd=0xad326c0)
   at /newdata/mysql-8.0.23/sql/sql_show.h:186

這個過程只是簡單的語句，也就是規(guī)則中定義的simple_statement 比如show/analyze/unlock/lock等等，具體可以參考yacc/bsion規(guī)則中的定義，感覺就是那種不需要執(zhí)行計(jì)劃的語句，這個類型的語句都可以根據(jù)這種方法進(jìn)行分析。
對于select語句顯然語法分析的結(jié)果是將生成AST樹后進(jìn)行實(shí)例化后進(jìn)入優(yōu)化器進(jìn)行執(zhí)行計(jì)劃生成，肯定要比簡單類型的語句復(fù)雜得多，后面我們在做分析。

最后

在執(zhí)行show engine的時候他的狀態(tài)幾乎就是show processlist的starting 狀態(tài)，如下：

image.png

因此如果show engine語句在打印innodb信息的時候出現(xiàn)了很慢的情況，show processlist 看到的應(yīng)該是starting，如下：

image.png

這個時候需要借助其他手段進(jìn)行分析了比如pstack。