Mysql实战45讲学习详情----一条SQL更新语句是如何执行的?

相关词语:

  redo log:日志模块(临时记录,类似于便签),InnoDB 引擎特有日志

  WAL(Write-Ahead Logging):写入方式

  binlog:日志模块(归档日志),Server 层的日志

  crash-safe:redo log带来的好处(MySQL 可以恢复到固定时间内任意一秒的状态)

 

WAL执行过程(redo log日志的存储方式):

 Mysql实战45讲学习详情----一条SQL更新语句是如何执行的?_第1张图片

 

write pos 是当前记录的位置,checkpoint 是当前要擦除的位置,它们之间的是“便签”上还空着的部分。如果 write pos 追上 checkpoint,表示“粉板”满了,这时候不能再执行新的更新,得停下来先擦掉一些记录,把 checkpoint 推进一下。

redo log 与binlog的不同点:

  redo log 是 InnoDB 引擎特有的;binlog 是 MySQL 的 Server 层实现的,所有引擎都可以使用。

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

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

首先update语句会把查询语句的流程先走一遍,区别就在与涉及到的两个日志模块:

  update T set c=c+1 where ID=2;

  1.连接数据库(连接器工作)

  2.清空查询缓存(查询缓存工作)--》更新语句会清空更新表的查询缓存

  3.分析词法和语法(分析器工作)--》得到这是一条更新语句

  4.优化器决定使用ID这个索引(优化器工作)--》决定执行方案

  5.执行器开始执行(执行器工作)--》找到这一行,进行更新

  更新过程中,执行器与引擎的交互:

    Mysql实战45讲学习详情----一条SQL更新语句是如何执行的?_第2张图片

      此处将redo log 的写入拆成了两个步骤:prepare 和 commit,这就是"两阶段提交"。

为什么需要“两阶段提交“呢?

是为了让两份日志之间的逻辑保持一致。

  这里就可以说说crash-safe功能是怎么实行的了。

  crash-safe(例如):怎样让数据库恢复到半个月内任意一秒的状态?

  binlog 会记录所有的逻辑操作,并且是采用“追加写”的形式。如果需要半个月内可以恢复,那么备份系统中一定会保存最近半个月的所有 binlog,同时系统会定期做整库备份。这里的“定期”取决于系统的重要性,可以是一天一备,也可以是一周一备。

     当需要恢复到指定的某一秒时,比如某天下午两点发现中午十二点有一次误删表,需要找回数据,那你可以这么做:

      1.找到最近的一次全量备份

      2.从这个备份恢复到临时库

      3.从备份的时间点开始,将备份的 binlog 依次取出来,重放到中午误删表之前的那个时刻。

  而redo log 和 binlog 是两个独立的逻辑,如果不用两阶段提交,要么就是先写完 redo log 再写 binlog,或者采用反过来的顺序。我们看看这两种方式会有什么问题。

    ①,先写 redo log 后写 binlog。

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

    ②,先写 binlog 后写 redo log。

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

  简单说,redo log 和 binlog 都可以用于表示事务的提交状态,而两阶段提交就是让这两个状态保持逻辑上的一致。

总结:

  redo log 用于保证 crash-safe 能力。

  nnodb_flush_log_at_trx_commit 这个参数设置成 1 的时候,表示每次事务的 redo log 都直接持久化到磁盘。(可以保证 MySQL 异常重启之后数据不丢失)

  sync_binlog 这个参数设置成 1 的时候,表示每次事务的 binlog 都持久化到磁盘。(可以保证 MySQL 异常重启之后 binlog 不丢失)

  两阶段提交是跨系统维持数据逻辑一致性时常用的一个方案,即使你不做数据库内核开发,日常开发中也有可能会用到。   

【附加问题】

  定期全量备份的周期“取决于系统重要性,有的是一天一备,有的是一周一备”。那么在什么场景下,一天一备会比一周一备更有优势呢?或者说,它影响了这个数据库系统的哪个指标?

【个人理解】

  首先我理解的数据备份是为了恢复数据,假如需要恢复的是上周的数据,那么一周一备份就需要整周全备+需要恢复的数据时间点binlog来恢复,一天一备的话只需要当天的全备+这天某个时间段的binlog来恢复,那么一天已备份的优势就在于恢复丢失数据时的工作量。

  其次就是数据丢失时的确认时间,天备只需要确认当天的binlog完好无损,而周备需要确认一整周的binlog完好。

你可能感兴趣的:(Mysql实战45讲学习详情----一条SQL更新语句是如何执行的?)