MySQL随笔02_一条SQL更新语句是如何执行的

一、回顾一条查询语句的执行过程

一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等阶段后,最后到达存储引擎。

二、更新语句的执行过程

更新SQL语句的执行过程与查询的基本一致。通过分析器的词法和语法解析判断出是一条更新语句,优化器决定使用的索引等,执行器负责具体执行,找到数据行后进行更新。

更新语句的执行流程涉及到两个重要的日志模块——redo log(重做日志) 和 binglog(归档日志)。

redo log 是 InnoDB 的日志模块,binglog 是 Server 层的日志模块。

三、重要的日志模块——redo log

MySQL在做更新操作的时候,如果每一次的更新都要写进磁盘,整个过程的IO成本、数据查询成本比较高,为了解决这类问题,MySQL从设计上采用了类似粉板+账本

的思路来提升更新效率。

粉板+账本配合的过程,其实就是MySQL中的WAL技术(Write-Ahead Logging),其关键点在于先写日志,再写磁盘

日志文件

InnoDB的redo log 文件是固定大小的,可配置一组4个文件,每个文件大小1GB,则总共可以记录4GB的操作。

从头开始写,写到末尾就又回到起始位置循环写,如下图所示:

file
crash-safe

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

四、重要的日志模块——binglog

MySQL从整体上来看,主要就两块:

  1. Server 层 ,主要做的是MySQL功能层面的事情;

  2. 引擎层,负责存储相关的具体事宜。

为什么会有两份日志

因为最开始的时候 MySQL 中并没有 InnoDB 引擎,只有自带的 MyISAM 引擎,而 MyISAM 自身并没有 crash-safe能力,binglog 日志只能用于归档。后来开发的 InnoDB 引擎 以插件的形式引入MySQL,由于当时依赖的binglog 没有 crash-safe 能力,所以InnoDB使用了通过 redo log 来实现 crash-safe 能力的日志系统。

两种日志的区别
  1. redo log 是 InnoDB 引擎特有的;binglog 是MySQL的 Server 层实现的,所有引擎共用。
  2. redo log 是物理日志;binglog 是逻辑日志。
  3. redo log 是循环写的,空间固定会用完;binglog 是可以追加写入的。

五、执行器和InnoDB执行update语句的内部流程

简单的update语句如下:

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

相应的执行流程图如下,其中浅色表示InnoDB内部执行的,深色表示在执行器中执行的。

file

如上图,执行器 写完binglog后,调用引擎的提交事务接口,引擎把上面刚刚写入的redo log改成 commit 状态,更新完成。

六、两阶段提交

上面流程图中的最后三个步骤,将 redo log 的写入拆解成两个步骤:preparecommit 就是 两阶段提交

两阶段提交的作用

为了让两份日志之间保持逻辑一致,以便在数据发送异常需要进行数据恢复时,可以准确进行数据恢复。

为什么日志需要两阶段提交

redo log 和 binglog 是两个独立的逻辑,若不使用两阶段提交,即先写 redo log 再写 binglog 或先写 binglog 再写 redo log,这两种方式存在的问题。

  1. 先写 redo log 后写 binglog。假设在redo log写完,binglog还没有写完的时候,MySQL异常重启,由于redo log 具有 crash-safe 能力,系统即使崩溃,仍然能够把数据恢复回来。但是由于binglog未写完就崩溃了,此时binglog中没有记录到崩溃前的语句,因此之后备份日志时,存起来的binglog中缺失语句。最后通过binglog日志进行数据恢复到临时库时,恢复出来的数据与原库值不一致。
  2. 先写 binglog 后写 redo log。假设在binglogx写完之后 crash,由于redo log还没有写,崩溃恢复后操作的事务无效,但是binglog里面已经记录了某个修改的操作日志。 所以在之后用binglog恢复时就多出来一个事务,与原库的值不一致。

由此可知,若是不使用两阶段提交,数据库的状态就有可能和用他的日志恢复出来的库的状态不一致。

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

七、小结

MySQL中最重要的两个日志——物理日志redo log 和 逻辑日志binglog。

redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit参数为1用于设置每次事务的redo log都直接持久化到磁盘。建议设置为1以保证MySQL异常重启后数据不丢失。

sync_binglog参数值为1用于设置每次事务的binglog都持久化到磁盘,建议设置为1以保证MySQL异常重启后binglog不丢失。

MySQL日志系统中的两阶段提交。两阶段提交是跨系统维持数据逻辑一致性时常用的方案。

八、思考题

定期全量备份的周期,在什么场景下,一天一备比一周一备更有优势?它影响数据库系统的哪个指标?

参考解答:

一天一备的好处是“最长恢复时间”更短,在此模式中,最坏的情况下需要应用一天的binglog。而一周一备最坏的情况下要应用一周的binglog。

系统对应的指标——RTO 恢复目标时间。

更频繁的全量备份需要消耗更多的存储空间,所以RTO是成本换来的,具体根据业务来评估选择备份模式。

本随笔源课程: https://time.geekbang.org/column/article/68633
本文由博客一文多发平台 OpenWrite 发布!

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,204评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,091评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,548评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,657评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,689评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,554评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,302评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,216评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,661评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,851评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,977评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,697评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,306评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,898评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,019评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,138评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,927评论 2 355