本文将在MySQL源码探索系列技术博客的第1篇的基础上接着分析dispatch_command()函数之后的工作流程，主要是分析mysql_parse()和mysql_execute_command()两个函数的代码框架，并对其中涉及到的隐式事务如何判断等等问题结合MySQL源码进行了介绍。
本人技术博客网址：
https://www.cnblogs.com/coe2coe/
其中可以找到MySQL源码探索系列博客和MySQL其它系列博客，以及其它相关的技术系列的博客。
1.mysql_parse
前面已经看到了MySQL服务器接收到SQL命令后最终到了dispatch_command()函数中进行处理。dispatch_command()的核心功能是调用了mysql_parse()函数。
mysql_parse()函数的精简代码如下图所示，为了更加直观的描述这个函数的作用，对代码布局也做了一定的调整。
图1
mysql_parse()的核心功能如下：
（1）判断SQL是否在查询缓存中，如果查询缓存命中，则直接发送结果给mysql客户端，同时记录日志，查询过程结束。如果没命中，或者在缓存中但是没权限使用，则执行后续过程进行实际的查询操作。对于查询缓存的具体细节，本文不做展开描述。
（2）解析SQL。这个过程实际上使用bison开源框架产生的代码进行语法解析，限于篇幅，本文不做展开描述。如果对如何使用bison和flex开源框架产生语法解析代码这方面的内容感兴趣，可以阅读本人的另一个系列的技术博客：
MySQL技术探索01实现SQL语法解析器
https://www.cnblogs.com/coe2coe/p/9743701.html
（3）对原始SQL语句进行重写。主要作用是防止在日志中出现明文的密码字符串。比如下面的这个SQL语句中含有密码，因此将会被rewrite修改。
图2
最终日志中的SQL信息如下，其中的密码字符串显示为<secret>。
图3
MySQL不会对所有的SQL进行rewrite，只会对涉及明文密码的SQL进行重写，还有一类比较特殊的SQL也会进行重写。这个工作是在mysql_rewrite_query()函数中执行的。mysql_rewrite_query()函数大致内容如下：
图4
（4）记录日志。如果SQL进行了rewrite，则将rewrite后的SQL语句写入到日志中，否则将原始日志写入到日志中。
执行SQL命令。真正执行SQL命令，实际调用mysql_execute_command()函数进行执行。稍后具体介绍这个函数。
2.mysql_execute_command
前面提到了mysql_parse()函数调用了mysql_execute_command()函数来执行SQL命令，现在来看一下这个函数真正完成的工作有哪些。精简后的代码框架如下图所示：
图5
（1）如果存在需要提交的隐式事务，则提交隐式事务。具体来讲，MySQL定义了四种可能需要隐式提交事务的SQL命令：
SQLCOM_DROP_TABLE
SQLCOM_ALTER_TABLE
SQLCOM_CREATE_TABLE
SQLCOM_SET_OPTION
在stmt_causes_implicit_commit()这个函数中做了是否需要隐式提交事务的判断。
（i）对于SQLCOM_CREATE_TABLE和SQLCOM_ALTER_TABLE命令，并不是都需要隐式提交事务，对于创建和修改临时表则不需要隐式提交事务。
（ii）对于SQLCOM_SET_OPTION命令，只有执行set autocommit=1时，则需要隐式提交事务,对于其他的SET命令，则不需要。
（iii）对于SQLCOM_DROP_TABLE命令，当删除一个临时表时，也不需要隐式提交事务。
隐式提交的执行是在trans_commit_implicit()函数中进行的。
（2）隐式提交一个事务不会自动释放已经存在的表锁，在mysql_execute_command()中还调用release_transactional_locks()函数执行了释放元数据锁的操作。元数据锁工作在MySQL 的Server层，跟Innodb 存储引擎层的记录锁、间隙锁以及下一键锁(next-key lock)这些锁相比，元数据锁是完全不同的概念，MySQL的表锁就是一种元数据锁，也可以细分为N种类型，在此不详细展开了。
（3）根据不同的SQL命令，执行不同的操作。包括创建和删除数据库，创建和删除表，数据的增删改查，以及其它很多的SQL命令。全部的SQL命令的ID在enum_sql_command中定义，后文将列出全部的SQL命令ID。
（4）关闭当前打开的所有表。这个关闭的操作时在close_thread_tables()函数中进行的。这个函数所做的工作如下图所示：
图6
如果当前语句处在自动提交事务中，则自动提交隐式事务。SQL命令执行之后的隐式提交条件的判断条件跟执行之前的判断条件在细微处可能相同，也可能不同。不同之处主要是涉及到一个全局数组变量：
图7
这个变量在init_update_queries()这个函数中做了初始化操作，基本上属于每个SQL命令ID有一个对应的标志。
前面介绍的判断函数stmt_causes_implicit_commit()在最前面还有以下这个判断：
图8
意思是说，如果mask标志没有包含在命令ID对应的标志位掩码中，就认为不需要隐式提交，这个判断确定不需要隐式提交后，就不会再进行前面介绍的临时表相关的判断了。只有这个mask标志符合数组中指定的标志位掩码时，才会继续进行后面的临时表相关判断。
前面介绍的SQLCOM_CREATE_TABLE就使用了下面这个标志，说明CREATE TABLE命令不管在SQL命令之前还是执行后，判断是相同的。
图9
从当前的MySQL源代码来看，前面提到的四个SQL命令都使用了CF_AUTO_COMMIT_TRANS这个标志位，因此都是在执行前后均需要继续判断。
3.SQL命令的ID
SQL命令的ID，在enum_sql_command中定义了。基本上根据ID的名字就能猜测出这个SQL语句的用途，因此本文不会具体介绍每个SQL命令的用途。这里的SQL命令的ID，和前面博客中介绍的命令交互中的命令的种类，是两个不同层次的概念。前文提出的命令的种类，是高层命令，这里的SQL命令的ID，是低层命令，更为具体。这里列出的所有ID，在命令的种类这个高层次上，都属于一种类型：COM_QUERY。
enum enum_sql_command {
SQLCOM_SELECT,
SQLCOM_CREATE_TABLE,
SQLCOM_CREATE_INDEX,
SQLCOM_ALTER_TABLE,
SQLCOM_UPDATE,
SQLCOM_INSERT,
SQLCOM_INSERT_SELECT,
SQLCOM_DELETE,
SQLCOM_TRUNCATE,
SQLCOM_DROP_TABLE,
SQLCOM_DROP_INDEX,
SQLCOM_SHOW_DATABASES,
SQLCOM_SHOW_TABLES,
SQLCOM_SHOW_FIELDS,
SQLCOM_SHOW_KEYS,
SQLCOM_SHOW_VARIABLES,
SQLCOM_SHOW_STATUS,
SQLCOM_SHOW_ENGINE_LOGS,
SQLCOM_SHOW_ENGINE_STATUS,
SQLCOM_SHOW_ENGINE_MUTEX,
SQLCOM_SHOW_PROCESSLIST,
SQLCOM_SHOW_MASTER_STAT,
SQLCOM_SHOW_SLAVE_STAT,
SQLCOM_SHOW_GRANTS,
SQLCOM_SHOW_CREATE,
SQLCOM_SHOW_CHARSETS,
SQLCOM_SHOW_COLLATIONS,
SQLCOM_SHOW_CREATE_DB,
SQLCOM_SHOW_TABLE_STATUS,
SQLCOM_SHOW_TRIGGERS,
SQLCOM_LOAD,
SQLCOM_SET_OPTION,
SQLCOM_LOCK_TABLES,
SQLCOM_UNLOCK_TABLES,
SQLCOM_GRANT,
SQLCOM_CHANGE_DB,
SQLCOM_CREATE_DB,
SQLCOM_DROP_DB,
SQLCOM_ALTER_DB,
SQLCOM_REPAIR,
SQLCOM_REPLACE,
SQLCOM_REPLACE_SELECT,
SQLCOM_CREATE_FUNCTION,
SQLCOM_DROP_FUNCTION,
SQLCOM_REVOKE,
SQLCOM_OPTIMIZE,
SQLCOM_CHECK,
SQLCOM_ASSIGN_TO_KEYCACHE,
SQLCOM_PRELOAD_KEYS,
SQLCOM_FLUSH,
SQLCOM_KILL,
SQLCOM_ANALYZE,
SQLCOM_ROLLBACK,
SQLCOM_ROLLBACK_TO_SAVEPOINT,
SQLCOM_COMMIT,
SQLCOM_SAVEPOINT,
SQLCOM_RELEASE_SAVEPOINT,
SQLCOM_SLAVE_START,
SQLCOM_SLAVE_STOP,
SQLCOM_START_GROUP_REPLICATION,
SQLCOM_STOP_GROUP_REPLICATION,
SQLCOM_BEGIN,
SQLCOM_CHANGE_MASTER,
SQLCOM_CHANGE_REPLICATION_FILTER,
SQLCOM_RENAME_TABLE,
SQLCOM_RESET,
SQLCOM_PURGE,
SQLCOM_PURGE_BEFORE,
SQLCOM_SHOW_BINLOGS,
SQLCOM_SHOW_OPEN_TABLES,
SQLCOM_HA_OPEN,
SQLCOM_HA_CLOSE,
SQLCOM_HA_READ,
SQLCOM_SHOW_SLAVE_HOSTS,
SQLCOM_DELETE_MULTI,
SQLCOM_UPDATE_MULTI,
SQLCOM_SHOW_BINLOG_EVENTS,
SQLCOM_DO,
SQLCOM_SHOW_WARNS,
SQLCOM_EMPTY_QUERY,
SQLCOM_SHOW_ERRORS,
SQLCOM_SHOW_STORAGE_ENGINES,
SQLCOM_SHOW_PRIVILEGES,
SQLCOM_HELP,
SQLCOM_CREATE_USER,
SQLCOM_DROP_USER,
SQLCOM_RENAME_USER,
SQLCOM_REVOKE_ALL,
SQLCOM_CHECKSUM,
SQLCOM_CREATE_PROCEDURE,
SQLCOM_CREATE_SPFUNCTION,
SQLCOM_CALL,
SQLCOM_DROP_PROCEDURE,
SQLCOM_ALTER_PROCEDURE,
SQLCOM_ALTER_FUNCTION,
SQLCOM_SHOW_CREATE_PROC,
SQLCOM_SHOW_CREATE_FUNC,
SQLCOM_SHOW_STATUS_PROC,
SQLCOM_SHOW_STATUS_FUNC,
SQLCOM_PREPARE,
SQLCOM_EXECUTE,
SQLCOM_DEALLOCATE_PREPARE,
SQLCOM_CREATE_VIEW,
SQLCOM_DROP_VIEW,
SQLCOM_CREATE_TRIGGER,
SQLCOM_DROP_TRIGGER,
SQLCOM_XA_START,
SQLCOM_XA_END,
SQLCOM_XA_PREPARE,
SQLCOM_XA_COMMIT,
SQLCOM_XA_ROLLBACK,
SQLCOM_XA_RECOVER,
SQLCOM_SHOW_PROC_CODE,
SQLCOM_SHOW_FUNC_CODE,
SQLCOM_ALTER_TABLESPACE,
SQLCOM_INSTALL_PLUGIN,
SQLCOM_UNINSTALL_PLUGIN,
SQLCOM_BINLOG_BASE64_EVENT,
SQLCOM_SHOW_PLUGINS,
SQLCOM_CREATE_SERVER,
SQLCOM_DROP_SERVER,
SQLCOM_ALTER_SERVER,
SQLCOM_CREATE_EVENT,
SQLCOM_ALTER_EVENT,
SQLCOM_DROP_EVENT,
SQLCOM_SHOW_CREATE_EVENT,
SQLCOM_SHOW_EVENTS,
SQLCOM_SHOW_CREATE_TRIGGER,
SQLCOM_ALTER_DB_UPGRADE,
SQLCOM_SHOW_PROFILE,
SQLCOM_SHOW_PROFILES,
SQLCOM_SIGNAL,
SQLCOM_RESIGNAL,
SQLCOM_SHOW_RELAYLOG_EVENTS,
SQLCOM_GET_DIAGNOSTICS,
SQLCOM_ALTER_USER,
SQLCOM_EXPLAIN_OTHER,
SQLCOM_SHOW_CREATE_USER,
SQLCOM_SHUTDOWN,
SQLCOM_ALTER_INSTANCE,
SQLCOM_END
};
4.总结
SQL语句的总体执行流程就是这样的。本文关注的主要问题是SQL语句的执行过程的总体流程，因此分析到mysql_execute_command()函数这一层就足够了。再往更低层次分析，就涉及到具体的SQL语句的类型的区分了，比如SELECT语句肯定和INSERT语句的具体执行过程是不同的。这种细分显然并不是本文需要关注的主体内容。
至于具体的一个SQL语句在更低级的层次上是如何执行的细节问题，以后有机会再对MySQL服务器的源码做进一步的探索。
本人技术博客网址：
https://www.cnblogs.com/coe2coe/
其中可以找到MySQL源码探索系列博客和MySQL其它系列博客，以及其它相关的技术系列的博客。