MySQL Update SQL语句执行顺序

redo log重做日志

N

Y

为什么要用两个日志模块，用一个日志模块不行吗?这是因为最开始 MySQL 并没与 InnoDB 引擎( InnoDB 引擎是其他公司以插件形式插入 MySQL 的) ，MySQL 自带的引擎是 MyISAM，但是我们知道 redo log 是 InnoDB 引擎特有的，其他存储引擎都没有，这就导致会没有 crash-safe 的能力(crash-safe 的能力即使数据库发生异常重启，之前提交的记录都不会丢失)，binlog 日志只能用来归档。并不是说只用一个日志模块不可以，只是 InnoDB 引擎就是通过 redo log 来支持事务的。

通过

是否准备完成

执行器收到通知

回滚

结束

存在

commit

连接器

查询缓存

执行器调用存储引擎去执行

如果采用 redo log 两阶段提交的方式就不一样了，写完 binglog 后，然后再提交 redo log 就会防止出现上述的问题，从而保证了数据的一致性。那么问题来了，有没有一个极端的情况呢？假设 redo log 处于预提交状态，binglog 也已经写完了，这个时候发生了异常重启会怎么样呢？ 这个就要依赖于 MySQL 的处理机制了，MySQL 的处理过程如下：•  判断 redo log 是否完整，如果判断是完整的，就立即提交。font color=\"#000000\

update tb set age=19 where id = 1；

prepare阶段

返回数据行并更新

用两个日志模块，但是不要这么复杂行不行，为什么 redo log 要引入 prepare 预提交状态？这里我们用反证法来说明下为什么要这么做？1、先写 redo log 直接提交，然后写 binlog假设写完 redo log 后，机器挂了，binlog 日志没有被写入，那么机器重启后，这台机器会通过 redo log 恢复数据，但是这个时候 binlog 并没有记录该数据，后续进行机器备份的时候，就会丢失这一条数据，同时主从同步也会丢失这一条数据。2、先写 binlog，然后写 redo log假设写完了 binlog，机器异常重启了，由于没有 redo log，本机是无法恢复这一条记录的，但是 binlog 又有记录，那么和上面同样的道理，就会产生数据不一致的情况。

查询该用户的所有权限

身份认证校验连接名和密码

分析器提取关键字语法分析权限校验

放置内存

磁盘中读入内存

记录binlog归档日志

redo log 重做日志

之后在这个连接里的权限逻辑判断都是会依赖此时读取到的权限数据，后续只要这个连接不断开，即时管理员修改了该用户的权限，该用户也是不受影响的