文档章节

02.MySQL实战45讲学习笔记---日志系统:一条SQL更新语句是如何执行的?

scgaopan
 scgaopan
发布于 11/19 00:15
字数 1445
阅读 30
收藏 0

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

   我们还是从一个表的一条更新语句说起,我们创建下面一张表:

create table T(ID int primary key, c int);

   如果要将ID=2这一行c的值加1,SQL可以这么写:

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

   前一篇文章介绍过SQL语句基本的执行链路,可以确认的说,查询语句的那一套流程,更新语句也是同样会走一遍。在执行语句前要先连接数据库,这是连接器的工作。接下来,分析器会通过词法和语法解析知道这是一条更新语句,优化器决定要使用ID这个索引。然后执行器负责具体执行,找到这一行,然后更新。

  与查询流程不一样的是,更新流程还涉及两个重要的日志模块:redo log(重做日志)和binlog(归档日志)。

  • redo log

  MySQL里面经常说到的WAL技术的全称是Write-Ahead Logging,它的关键点就是行写日志再写磁盘。具体来说,当有一条记录需要更新的时候,InnoDB引擎会先把记录写到redo log里面,并更新内存,这个时候更新就算完成了。同时InnoDB引擎会在适当的时候,将这个操作记录更新到磁盘里面,而这个更新往往是在系统比较闲的时候做。

  InnoDB的redo log是固定在小的,比如可以配置为一组4个文件,每个文件的大小是1GB,那么总共就可以记录4GB的操作,如图所示:

   从头开始写,写到末尾又回到开头循环写,write pos是当前记录的位置,一边写一边后移,写到3号文件末尾后就回到0号文件开头。checkpoint是当前要擦除的位置,擦出记录前要把记录更新到数据文件中。如果write pos追上checkpoint,这个时候不能再执行新的更新,得停下来先擦除一些记录,把checkpoint推进一下。

   有了redo log,InnoDB就可以保证即使在数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为crash-safe。  

  • binlog

  MySQL整体来看,其实就两块:一块是Server层,它主要做的是MySQL功能层面的事情;还有一块就是引擎层,负面存储相关的具体事宜,上面说到的redo log是InnoDB引擎特有的日志,而Server层也有自己的日志,称为binlog。

 为什么会有两份日志呢?因为最开始MySQL并没有InnoDb引擎,MySQL自带的引擎是MyISAM,但MyISAM并没有crash-safe能力,binlog日志只能用于归档。

redo log日志和binlog日志有以下3个不同点:

  1. redo log 是InnoDB引擎特有的;binlog 是MySQL的Server层实现的,所有引擎都可以使用。
  2. redo log 是物理日志,记录的是“在某个数据页上做了什么修改”;binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段+1"。
  3. redo log 是循环写的,空间固定会用完;binlog是可以追加写入的,“追加写”是指binlog文件写到一定的大小后会切换到下一个,并不会覆盖以前的日志。

那么执行一个简单的update语句的内部流程如下:

  1. 执行器先找引擎取ID=2这一行,ID是主键,引擎直接用树搜索找到这一行,如果ID=2这一行所在的数据页本来就在内存中,就直接返回给执行器;否则,需要先从磁盘读入内存,然后返回。
  2. 执行器拿到引擎返回的行数据,把这个值+1,行到新的一行数据,再调用引擎接口写入这行新数据。
  3. 引擎将这行数据更新到内存中,同时将这个更新操作记录到redo log里面,此时redo log处理prepare状态,然后告知执行器执行完了,随时可以提交事务。
  4. 执行器生成这条操作的binlog,并把binlog写入磁盘。
  5. 执行器调用引擎的提交事务接口,引擎把刚刚写入redo log改成提交(commit)状态,更新完成。

将redo log的写入折成了两个步骤:prepare和commit,这就是“两阶段提交”。

  • 两阶段提交
  1. 先写redo log 后写binlog。假设在redo log写完后,binlog还没有写完的时候,MySQL进程异常重启,根据redo log恢复回来后这一行数据c=1,但由于binlog没有写完就crash了,这个时候binglog里面就没有这条更新语句,如果需要用这个binlog来恢复临时库的话,这个临时库就会少一次更新,恢复出来的数据c=0。
  2. 先写binlog后写redo log。如果binlog写完之后crash,由于redo log还没有写完,崩溃恢复后这个事务无效,所以这一行的c=0,但时,binlog里面已经记录了c=1,所以之后用binlog恢复出来的数据c=1写原库的值不同。

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

 

© 著作权归作者所有

scgaopan
粉丝 4
博文 59
码字总数 38302
作品 0
成都
私信 提问
MySQL 笔记整理(19) --为什么我只查一行的语句,也执行这么慢?

MySQL 笔记整理(19) --为什么我只查一行的语句,也执行这么慢? 笔记记录自林晓斌(丁奇)老师的《MySQL实战45讲》 (本篇内图片均来自丁奇老师的讲解,如有侵权,请联系我删除) 19) --...

优惠券活动
04/21
0
0
mysql_一条更新语句的执行流程

一条更新语句的执行流程 redo log(重做日志) binlog(归档日志) redo log是innoDB 引擎特有的日志。而binlog是mysql server层的日志。为什么要有两份日志: redo log和binlog的区别: 更新语句的...

grace_233
2018/11/22
296
0
一条sql语句在mysql中是如何执行的

概览 最近开始在学习mysql相关知识,自己根据学到的知识点,根据自己的理解整理分享出来,本篇文章会分析下一个sql语句在mysql中的执行流程,包括sql的查询在mysql内部会怎么流转,sql语句的...

木木匠
03/26
5.5K
14
mysql_一条查询语句的执行流程

mysql的逻辑架构 一条查询语句的执行流程 连接器 查询缓存 但是大多数情况下建议不要使用查询缓存,为什么呢?因为查询缓存往往弊大于利。 分析器 如果没有命中查询缓存,就要开始真正执行语...

grace_233
2018/11/22
106
0
开发人员MySQL调优-实战篇3-profile日志和锁

profile日志分析 通过使用explain命令查看执行计划,并对SQL调优后,如果还想对SQL执行过程更详细的了解,查找慢更底层的原因,可以使用profile分析。 打开日志记录 先查看profile配置 mysq...

特拉仔
2018/06/14
75
0

没有更多内容

加载失败,请刷新页面

加载更多

采购单品汇总_华南.xlsx

import pandas as pdimport matplotlib.pyplot as pltimport matplotlib as mp1mp1.rcParams["font.family"] = "STFangsong"# 加载《销售》表数据df1 = pd.read_excel(r"C:\Us......

龙玉滕
今天
5
0
OSChina 周五乱弹 —— 一次四千 要4次还能多给一千

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @这次装个文艺青年吧 :#今日歌曲推荐# 分享金志文的单曲《远走高飞》: 版权又回来了现在听歌得好几个软件 《远走高飞》- 金志文 手机党少年们...

小小编辑
今天
7
0
Spring Cloud Alibaba 实战(十) - Spring Cloud GateWay

> 本文主要内容是:为什么要使用网关,整合Gateway,Gateway核心学习:Route,Predicate,Filter,最后使用Gateway聚合微服务请求 先总结至此的架构 1 网关的价值 不使用网关行嘛? 各个请求直接打在...

JavaEdge
今天
4
0
【CKB.DEV 茶话会】第二期:聊聊 CKB 钱包和 Nervos DAO 全流程

CKB.DEV 茶话会第二期:聊聊 CKB 钱包和 Nervos DAO 全流程 为了鼓励更多优秀的开发者和研究人员参与到 CKB 的开发和生态建设中去,我们希望组织一系列 CKB Developer Seminar(CKB.DEV 茶话...

NervosCommunity
今天
4
0
聊聊rocketmq的HAClient

序 本文主要研究一下rocketmq的HAClient HAClient rocketmq-all-4.6.0-source-release/store/src/main/java/org/apache/rocketmq/store/ha/HAService.java class HAClient extends Serv......

go4it
昨天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部