有一条SQL语句，给到MySQL,是怎么被执行的
基本架构
**连接器：**进行身份认证，确定操作权限
查询缓存： 执行查询语句时，先查询缓存（不太实用，MySQL 8.0 版本后删了）
分析器：第一 分析SQL语句功能，提取关键字，比如 select，查哪张表，查哪些字段名，查询条件是啥等，第二检查语法是否正确
优化器：按MYSQL认为最优的方式执行，比如多个索引如何选索引，多表查询如何选关联顺序
执行器：执行语句，执行前会校验用户有没有权限，没有权限，报错，有权限从存储引擎返回数据
Server 层：包括图中的，实现所有跨存储引擎的功能：存储过程、触发器、视图，函数，加上一个通用的binlog日志模块 。
存储引擎：负责数据存储和读取，采用可以替换的插件式架构，支持 InnoDB、MyISAM、Memory 等多个存储引擎，其中 InnoDB 引擎有自有的 redolog 日志模块。最常用的存储引擎: InnoDB，从 MySQL 5.5 开始做默认存储引擎。
查询语句的执行流程如下：权限校验（如果命中缓存）--->查询缓存--->分析器--->优化器--->权限校验--->执行器--->引擎
查询不用记录日志。
更新语句执行流程如下：分析器---->权限校验---->执行器--->引擎---redo log(prepare 状态)--->binlog--->redo log(commit 状态
更新需要记录日志。
怎么记？记在哪里？
MySQL 自带日志模块是 binlog（归档日志） ，所有的存储引擎都可以使用， InnoDB 引擎还自带一个日志模块 **redo log（重做日志）。**两个日志都要记。binlog用来和主从同步，redo log用来数据库崩溃数据恢复和支持事务。而且两个日志记的东西要一样。
先写redo log写完进入prepare阶段
在写binlog，成功后 redo log进行commit
为啥要这样的顺序写？
**先写 redo log 直接提交，然后写 binlog：**假设写完 redo log 后，机器挂了，binlog 日志没有被写入，机器重启后，这台机器会通过 redo log 恢复数据，但是 binlog 并没有记录该数据，后续进行机器备份的时候，会丢失这条数据，同时主从同步也会丢失这条数据。
**先写 binlog，然后写 redo log：**假设写完 binlog，机器异常重启，由于没有 redo log，本机无法恢复这条记录，但是 binlog 又有记录，同上，会产生数据不一致的情况。
极端的情况： redo log 处于预提交状态，binlog 也已经写完了，这个时候发生了异常重启。
MySQL 处理过程：
- 判断 redo log 是否完整，如果判断是完整的，就立即提交。
- 如果 redo log 只是预提交但不是 commit 状态，这个时候就会去判断 binlog 是否完整，如果完整就提交 redo log, 不完整就回滚事务。