欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

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

程序员文章站 2022-03-14 14:23:21
相关词语: redo log:日志模块(临时记录,类似于便签),InnoDB 引擎特有日志 WAL(Write-Ahead Logging):写入方式 binlog:日志模块(归档日志),Server 层的日志 crash-safe:redo log带来的好处(MySQL 可以恢复到固定时间内任意一 ......

相关词语:

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

  wal(write-ahead logging):写入方式

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

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

 

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

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

 

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更新语句是如何执行的?

      此处将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完好。