找网站做任务领q币,免费搭建私人网站,深圳品牌公寓,百度seo关键词报价文章目录 理解执行流程衍生知识redo logbinlog 本篇文章是基于《MySQL45讲》来写的个人理解与感悟。 理解
先看下图#xff1a; 上一篇文章我们讨论了一条SQL查询语句的执行流程#xff0c;并介绍了执行过程中涉及的处理模块。 回顾一下#xff1a;
大体来说#xff0c;… 文章目录 理解执行流程衍生知识redo logbinlog 本篇文章是基于《MySQL45讲》来写的个人理解与感悟。 理解
先看下图 上一篇文章我们讨论了一条SQL查询语句的执行流程并介绍了执行过程中涉及的处理模块。 回顾一下
大体来说MySQL可以分为Server层和存储引擎层两部分。就是对应着图中的两个圈。
server层包含查询缓存、分析器、优化器、执行器等以及及所有的内置函数如日期、时间…所有跨存储引擎的功能都在这一层实现比如存储过程、触发器、视图等。
存储引擎层负责数据的存储和提取而存储引擎架构模式是插件式的有很多种比如持InnoDB、MyISAM、Memory等这也就意味着也就是说不同存储引擎共用一个server层。
即一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块最后到达存储引擎。 如果有不太清楚的小伙伴可以去下面的文章进行阅读因为执行和更新语句的流程其实差别不是特别大所以先去了解执行流程之后再来看本篇文章那么就很清晰易懂了 上篇文章链接在下面 文章链接谈一谈一条SQL查询语句究竟是如何执行的?
执行流程 背景信息
下面是这个表的创建语句这个表有一个主键ID和一个整型字段c
create table T(id int primary key,c int
);如果要将ID2这一行的值加1SQL语句就会这么写
update T set cc1 where ID2;可以确定的说查询语句的那一套流程更新语句必然同样会走一遍但是会有稍许不同接下来进行介绍。 更新流程区别
首先建立连接然后当走到在查询缓存的时候更新表的操作会导致缓存的清空【区别】所以这个时候T表的所有缓存结果都清空。 这也是为什么一般不建议使用查询缓存的原因。 接下来分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用ID这个索引。然后执行器负责具体执行找到这一行然后更新…
更新语句的流程会涉及到 undo log回滚日志、redo log重做日志 、binlog 归档日志这三种日志
undo log回滚日志是 Innodb 存储引擎层生成的日志实现了事务中的原子性主要用于事务回滚和 MVCC。redo log重做日志 是 Innodb 存储引擎层生成的日志实现了事务中的持久性主要用于掉电等故障恢复binlog 归档日志是 Server 层生成的日志主要用于数据备份和主从复制
衍生知识
redo log 我们先来看个小故事
在《孔乙己》这篇文章酒店掌柜有一个粉板专门用来记录客人的赊账记录。
如果赊账的人不多那么他可以把顾客名和账目写在板上。但如果赊账的人多了粉板总会有记不下的时候但是这个时候掌柜一定还有一个专门记录赊账的账本。
如果有人要赊账或者还账的话掌柜一般有两种做法 1. 直接把账本翻出来把这次赊的账加上去或者扣除掉 2. 先在粉板上记下这次的账等打烊以后再把账本翻出来核算。
在生意红火柜台很忙时掌柜一定会选择后者因为前者操作实在是太麻烦了。 首先你得找到这个人的赊账总额那条记录。你想想密密麻麻几十页掌柜要找到那个名字可能还得带上老花镜慢慢找找到之后再拿出算盘计算最后再将结果写回到账本上。
这整个过程想想都麻烦。相比之下还是先在粉板上记一下方便。你想想如果掌柜没有粉板的帮助每次记账都得翻账本效率是不是低得让人难以忍受 而粉板和账本配合的整个过程其实就是MySQL里经常说到的WAL技术【写时复制】它的关键点就是先写日志再写磁盘也就是先写粉板等不忙的时候再写账本。
具体来说当有一条记录需要更新的时候InnoDB引擎就会先把记录写到redo log粉板里面并更新内存这个时候更新就算完成了。 同时InnoDB引擎会在适当的时候将这个操作记录更新到磁盘里面而这个更新往往是在系统比较空闲的时候做这就像打烊以后掌柜做的 事。
如果今天赊账的不多掌柜可以等打烊后再整理。但如果某天赊账的特别多粉板写满了又怎么办呢 这个时候掌柜只好放下手中的活儿把粉板中的一部分赊账记录更新到账本中然后把这些记录从粉板上擦掉为记新账腾出空间。
与此类似InnoDB的redo log是固定大小的比如可以配置为一组4个文件每个文件的大小是1GB那么这块“粉板”总共就可以记录4GB的操作。从头开始写写到末尾就又回到开头循环写如下图所示 write pos是当前记录的位置一边写一边后移写到第3号文件末尾后就回到0号文件开头。
checkpoint是当前要擦除的位置也是往后推移并且循环的擦除记录前要把记录更新到数据文件。
write pos到checkpoint的可以用来记录新的操作。如果write pos 追上checkpoint表示redo满了得停下来先擦掉一些记录把 checkpoint推进一下。 总结
当有一条记录需要更新的时候InnoDB引擎就会先把记录写到redo里并更新内存【这个时候更新就算完了】。同时InnoDB引擎会在适当的时候将这个操作记录更新到磁盘里面【往往是在系统比较空闲的时候做】。但是如果redo满了就不行了【redo的大小是固定的假设配置了4组1GB那么总共就是4GB。然后就是从头开始写写到末尾再重新从头开始写】
有了redo logInnoDB就可以保证即使数据库发生异常重启之前提交的记录都不会丢失这个 能力称为crash-safe。 要理解crash-safe这个概念可以想想我们前面赊账记录的例子。只要赊账记录记在了粉板上或 写在了账本上之后即使掌柜忘记了比如突然停业几天恢复生意后依然可以通过账本和粉板 上的数据明确赊账账目。
binlog
MySQL整体来看其实就两块一块是Server层它主要做的是MySQL功能层面的事情还有一块是引擎层负责存储相关的具体事宜。上面我们聊到的粉板redo log是InnoDB引擎特有的日志。而Server层也有自己的日志称为binlog归档日志。 为什么会有两份日志 因为最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM但是MyISAM没有crash-safe的能力binlog日志只能用于归档。 而InnoDB是另一个公司以插件形式引入MySQL的既然只依靠binlog是没有crash-safe能力的所以InnoDB使用另外一套日志系统— — 也就是redo log来实现crash-safe能力。 两种日志有以下三点不同 1. redo log是InnoDB引擎特有的binlog是MySQL的Server层实现的所有引擎都可以使用。 2. redo log是物理日志记录的是“在某个数据页上做了什么修改”binlog是逻辑日志记录的是这个语句的原始逻辑比如“给ID2这一行的c字段加1 ”。 3. redo log是循环写的空间固定会用完binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个并不会覆盖以前的日志。
下面我们再来看看看执行器和InnoDB引擎在执行下面更新语句的内部流程
update T set cc1 where ID2;先看图 执行器先找引擎取ID2这一行。ID是主键引擎直接用树搜索找到这一行。如果ID2这一 行所在的数据页本来就在内存中就直接返回给执行器否则需要先从磁盘读入内存然 后再返回。执行器拿到引擎给的行数据把这个值加上1比如原来是N现在就是N1得到新的一行数据再调用引擎接口写入这行新数据。引擎将这行新数据更新到内存中同时将这个更新操作记录到redo log里面此时redo log处于prepare状态。然后告知执行器执行完成了随时可以提交事务。执行器生成这个操作的binlog并把binlog写入磁盘。执行器调用引擎的提交事务接口引擎把刚刚写入的redo log改成提交**commit**状态更新完成。
最后三步看上去有点“绕”将redo log的写入拆成了两个步骤prepare和commit这就是两阶段提交。
为了保证事务的持久性和一致性MySQL需要确保redo log和binlog的同步持久化。MySQL通过“两阶段提交”的机制来实现在事务提交时这两个日志必须保持一致以避免出现数据不一致的问题。 PS 因为两阶段提交我之前写了一篇文章专门介绍所以就不在这里占用篇幅了大家可以点击下面链接进行查看。 文章链接谈一下MySQL的两阶段提交机制 ps: 至于undo log我会在接下来的相关的MVCC文章进行介绍所以有兴趣的小伙伴记得点个关注谢谢你的支持
