MySQL 一条SQL查询语句是如何执行的？
1 连接器
首先客户端需要先跟服务端进行连接
2 查询缓存
MySQL 5.7 以及之前的版本会查询MySQL缓存，存储是键值对形式的
分析器
对SQL进行词法分析【会生成词法树】以及语法分析
词法分析：
- 主要负责从 SQL 语句中提取关键字，比如：查询的表，字段名，查询条件等等。
- 词法分析阶段是从 information_schema 里面获得表的结构信息的。
语法分析：
- 判断输入的SQL 语句是否满足 MySQL 语法
- 如果 SQL 语句不对，就会返回 You have an error in your SQL syntax 的错误提醒，一般语法错误会提示第一个出现错误的位置，所以你要关注的是紧接“use near”的内容。
优化器
SQL 执行计划以及索引选择是在这步骤进行的
优化器的作用是在基于同一个查询语句的多个查询方案中找出效率最高的
执行器
判断是否有执行权限，返回查询结果
底层是存储引擎
MySQL 一条SQL更新语句是如何执行的？
UPDATE XX SET c = c+ 1 WHERE id = 2
1、执行器先获取到id=2这行。ID 是主键，引擎直接用树搜索找到这一行。如果ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2、执行器拿到引擎的行数据，把这个值更新a字段，调用存储引擎写入这行新数据
3、存储引擎会将新数据写入内存，同时将更新的记录存到redo log，redo log 处于prepare状态。告知执行器随时可以提交事务
4、执行器生成操作的binlog，并将binlog写入磁盘
5、执行器调用引擎的提交事务接口，引擎将写入的redo log改成提交(commit)状态，更新完成
整个过程使用了XA 两阶段提交保证日志（redo log、binlog）的一致性
如果在更新执行过程中，MySQL发送宕机，崩溃恢复怎么处理
崩溃恢复的判断规则
1、如果redo log事务是完整的，以及commit则直接提交
2、如果redo log里面的事务只是prepare，则判断事务binlog是否存在完整：
1.1 如果是，则提交事务
1.2 如果不是，则回滚事务
redo log 和 binlog 是怎么关联起来的?
通过XA的XID，分支ID进行关联
它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：
- 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
- 如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。
