一条sql的执行流程

上图展示了一条sql，进入到Mysql后需要经过哪些处理器处理，并最终获得数据的流程。

缓存器可以不考虑，在8.0之后的版本中已移除。主要看右边流程。

关于表权限的事情需要注意，表权限是在sql执行器调用引擎，打开表的时候进行校验的，如果当前用户没有表权限，则会报权限异常。

以上主要是查询语句的处理。在更新语句处理，其他流程几乎相同，主要涉及到binlog和redo log的二段提交确保数据一致。

binlog是server层的日志，redo log是innodb引擎层的日志方案。

redo log是4个指定大小的文件，文件写完会重头开始写。如下图。

binlog和redo log的区别如下：

1、binlog是mysql 的 server层日志，所有引擎都可以使用，但是redo log是innodb的日志，只有它可以使用。

2、redo log是复用指定的4个文件，写完后重头开始写，而binlog日志文件写满后就再创建一个文件。

3、redo log是物理日志，记录了一个数据做了什么样的修改，而binlog是逻辑日志，记录sql的原始逻辑。

继续上文，来了解一下一个更新语句的流程： update t set c = c+ 1 where id = 1;(id是主键索引)

1、引擎根据id查找该行数据，id是主键索引，所以直接根据树搜索找到该数据，如果数据所在数据页已经在内存中，则直接获取数据返回；否则去磁盘找到对应的数据页到内存中，再返回数据到执行器。

2、执行器拿到数据，对c值做赋值 c+1操作，得到新的一行数据，调用引擎接口，写入数据到引擎。

3、引擎将数据更新到内存中，然后写入redo log日志，此时redo log日志状态为prepare;然后告知执行器更新完成，随时可以提交。

4、执行器接受到引擎更新成功，生成Binlog日志，并写入磁盘中，告知引擎。

5、引擎将redo log状态改为commit .完成数据更新。

流程图如下：

 

其中将redo log分为prepare和commit2个状态提交，就是所谓的 两阶段提交。

为什么要用两阶段提交？

以 update t set c = c + 1 where id = 1;来说明。

1、如果先写redo log，后写binlog。如果redo log写完，binlog没写系统宕机。此时使用redo log做数据恢复，c 已经+1，但是如果用Binlog恢复数据，c并没有 +1,会导致数据不一致。

2、如果先写binlog ,后写redo log。 同理，如果redo log未写，binlog已写，此时恢复数据时，发现redolog没有记录，此事务无效，不做c+1操作，但是binlog中记录了此操作，如果用Binlog恢复数据，也会导致数据不一致。

在做扩容的时候，如果使用全量 + Binlog来做备库数据同步，也会导致数据不一致问题。

补充：

innodb_flush_log_at_trx_commit = 1 ;表示每次redo log都同步到磁盘中。

sync_binlog = 1 ;表示每次binlog同步到磁盘。

双1设置保证redo log 和binlog 数据不会丢，数据一致。