sql更新是如何执行的？

update from set a = 1 where id = 1复制代码

首先看一下一张图（图片来自 sql 查询是如何执行的?）

和查询类似，也会走同样的逻辑。

1. 创建连接。

2. 清除缓存。

3. 分析器 分析语法，检查表和字段是否存在。

4. 优化器，决定是否使用索引，使用哪一个索引。

5. 执行器。主要区别在这一层，下面说说我理解的具体区别。

与查询流程不同的是，更新涉及到redo_log (重做日志) 和 binlog（归档日志）

redo log

如果更新数据直接修改磁盘数据，会首先找到磁盘中的数据，然后在修改磁盘中的数据，io成本会很高。 所以 mysql 更新不会直接修改逻辑数据，而是先写到内存中，然后等mysql空闲之后，会同步到硬盘。

1. 作用在存储引擎上，innodb 特有的。

2. redo log 大小是固定的。类似一个环，每次写满之后会强制刷新，从头开始写。

3. redo log 会保证即使数据库发生异常，数据也不会丢失。

4. 物理日志，记录了在哪个数据页上的修改

binlog

作用在service层，是mysql的日志，所有存储引擎都可以使用。 记录了所有增删改的逻辑日志。

记录方式  statement   记录sql语句  row  记录每一行数据的改动，m ixed(混合模式) mysql会根据具体的sql来决定按照什么方式进行记录

执行器的执行流程

update t set a=a+1 where id=1;复制代码

1.  调用存储引擎接口，找到id=1这一条记录。如果数据在内存中直接返回，否则先从磁盘中读到内存，然后返回
2.  执行器拿到结果，进行+1操作，再调用存储引擎接口写入新数据。
3. 存储引擎将这行数据更新到内存，同时记录redo log(perpare) 然后返回成功
4. 执行器生成binlog，把binlog写入磁盘。
5. 调用引擎提交事务，把redo log 改成提交状态(commit)。更新完成

两阶段提交

上面redo log 2次写入被称为两阶段提交。

redo log 保证了及时异常重启，也会把数据刷新到磁盘中。binlog主要适用于数据备份的。

目的：因为redo log 和binlog 是2个完全不同的东西，一个是存储引擎实现的一个是数据库本身实现的。所以为了保证redo log 和binglog 的一致性，引入了两阶段提交。

uodo log 只是为了回滚使用，比如把name=‘a’ 修改为name = ‘b’ ，那么undo日志就会用来存放name=’a’的记录，如果这个修改出现异常，可以使用undo日志来实现回滚操作，保证事务的一致性。