mysql学习笔记2:update是如何执行的

select语句的执行过程会经过 连接器->查询缓存->分析器->优化器->执行器->存储引擎。

那么update语句呢？与select执行流程大致是一样的，只不过有一点需要注意：

1. 当进行更新操作时，与该表相关的查询缓存会被清除。

与select流程不同，更新的流程设计到mysql中两个重要的日志模快：

2. redo log （InnoDB:重做日志）
3. binlog (Server:归档日志)

一：redo log (重做日志)

1. 为什么需要redo log？
   在mysql中，数据的存储会持久化到磁盘当中。那么仔细想一想，如果在每一条更新操作时，都将信息写入磁盘，然后磁盘找到对应的记录并且更新，在整个过程中IO、查询的成本就会很高，所以就有了redo log。
2. redo log是InnoDB独有的功能。
3. redo log的工作流程
   当有数据进行更新时，InnoDB引擎会先把数据记录到redo log中，并更新至内存中。当在mysql压力不大的情况下，才会将这个机会更新到磁盘进行保存。

注：
   1.redo log的空间是固定大小的，当被写满时，这个时候边不会再执行新的更新操作，而是停下来，把原有的还未更新到磁盘中的记录写入磁盘并擦除掉。
   2.crash-safe：当数据库异常重启，之前提交的记录不会丢失。
   3.这就是mysql里经常说到的WAL(write-ahead logging)技术:先写日志，在写磁盘

二：binlog（归档日志）

还记得mysql主要分为两大模块：Server、存储引擎。

而binglog则属于Server，记录了mysql所有逻辑操作的动作，而mysql自带的引擎MyISAM并没有crash-safe功能，binlog只能用与归档（还原数据）。

三：redo log 与 binlog的区别

1. redo log属于物理日志，binlog属于逻辑日志，物理的速度始终是大于逻辑的速度。
2. redo log是InnoDB独有的，binlog是mysql Server实现的。
3. redo log是固定空间大小，循环写入，并不持久保存；binlog是可以追加写入的。

四：update执行过程

1. 首先根据条件搜到找到这一行：若内存中查询不到，则会从磁盘中读入内存再返回对应结果集。
2. 执行器进行修改处理
3. 引擎将新的数据更新到内存中，并同时将更新操作记录到redo log中，此时 redo log 处于 prepare 状态，最后告知执行器执行完成，准备提交事务。
4. 执行器调用引擎的提交事务接口，把刚redo log 的状态由 prepare -> commit ，此时更新完成。

五：2pc（两阶段提交）

由上述可知，redo log 的写入拆成了两个步骤： prepare和commit。为什么需要拆成两步呢？

redo log 与 binlog 属于两个独立的处理逻辑，如果不用两阶段提交方式的话会导致最终处理数据的不一致性：

1. 先写 redo log 后写 binlog ，此时 mysql异常崩溃了，redo log是可以在内存中找回数据的，但是由于binlog还没写完就crash了，所以不会记录修改的数据，之后再用binlog备份的数据就少了这次操作的信息。导致了与原库中数据不一致。
2. 先写binlog 后写 redo log，如果binlog之后crash了，由于redo log 还没写完，正常来说此时崩溃恢复无效，事务回滚，但是由于binlog已经记录了这次的操作，所以就会平白的多出了一次操作，之后再用binlog备份数据时就多了一次操作信息。导致了与原库数据不一致。
3. redo log 和 binlog 都可以表示事务的提交状态，而2pc则是让这两个状态保持逻辑上的一致

总结：

1. innodb_flush_log_at_trx_commit=1，表示redo log的每次事务都持久化到磁盘中。
2. sync_binlog=1，表示binlog的每次事务都持久化到磁盘中。
3. 1和2两个参数配置可以保证事务的成功性，日志必须落盘，这样数据库crash后就不会丢失某一个事务的数据。
4. binlog一般采用row模式，因为遇到时间，从库可能会出现不一致的情况，但是row模式更新前后都会存在，导致日志变大。