【MySql】02 笔记 一条SQL更新语句做了那些事情？

一、介绍

1、更新流程和查询流程类似

二、更新流程两个重要的日志模块

1、为什么需要日志模块？

1. 如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过 IO 成本、查找成本都很高。

2、redo log（重做日志）

1. WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

2. 当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log里面，并更新内存，这个时候更新就算完成了。InnoDB 引擎会在适当的时候，
   将这个操作记录更新到磁盘里面。比如：系统比较空闲的时候，记录日志的地方满了。

3. crash-safe:，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢
   失。

4. write pos 是当前记录的位置，checkpoint 是当前要擦除的位置。擦除记录前要把记录
   更新到数据文件。 write pos == checkpoint 表示满了。

3、binlog（归档日志）

MySQL自带的引擎是MyISAM，但是MyISAM没有crash-safe的能力，binlog日志只能用于归档。

4、redo log 与 binlog区别

1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。

2. redo log 是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，如“给 ID=2 这一行的 c 字段加 1 ”。

3. redo log 是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

5、给 ID=2 这一行的 c 字段加 1

1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果
   ID=2 这一行所在的数据页本来就在内存中直接返回给执行器；否则从磁盘
   读入内存返回。

2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新
   的一行数据，再调用引擎接口写入这行新数据。

3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时
   redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。

4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。

5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状
   态，更新完成。

三、两阶段提交

1、为什么必须有“两阶段提交”呢？

让两份日志之间的逻辑一致

2、不使用的问题？

redo log、binlog 先后顺序不一样 与数据不一致情况。

a）假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。redo log 写完之后，系统即使崩溃，仍然能够把数据恢复回来，恢复后这一行 c 的值是 1。由于 binlog 没写完就 crash 了，这时候 binlog 里面就没有记录这个语句。之后备份日志的时候，存起来的 binlog 里面就没有这条语句,如果需要用这个 binlog 来恢复临时库的话，由于这个语句的 binlog 丢
失，这个临时库就会少了这一次更新，恢复出来的这一行 c 的值就是 0，与原库的值不。
同。

b）先写 binlog 后写 redo log。如果在 binlog 写完之后 crash，redo log 还没写，
崩溃恢复以后这个事务无效，所以这一行 c 的值是 0。但是 binlog 里面已经记录了“把
c 从 0 改成 1”这个日志。在之后用 binlog 来恢复的时候就多了一个事务出来，
恢复出来的这一行 c 的值就是 1，与原库的值不同。

3、需要恢复临时库的场景

1. 误操作后需要用这个过程来恢复数据

2. 需要扩容的时候，再多搭建一些备库来增加系统的读能力的时候，现在常见的做法也是用全量备份加上应用binlog 来实现。