亲宝软件园·资讯

展开

初探Mysql架构和InnoDB存储引擎

H.U.C-王子 人气:0

前言

mysql相信大家都不陌生了,分享之前我们先思考几个面试题:

1.undo log和redo log了解过吗?它们的作⽤分别是什么?

2.redo log是如何保证事务不丢失的?

3.mysql的事务是先提交还是先刷盘?

4.更新操作为什么不直接更新磁盘反而设计这样⼀个复杂的InnoDB存储引擎来完成?

下面我们开始逐步探索Mysql架构的运行流程。

前台操作触发Mysql服务器执⾏请求

前台⽤户各种操作触发后台sql执⾏,通过web项⽬中⾃带的数据库连接池:如dbcp、c3p0、druid等,与数据库服务器的数据库连接池建⽴⽹络连接;

数据库连接池中的线程监听到请求后,将接收到的sql语句通过SQL接⼝响应给查询解析器,

查询解析器将sql按照sql的语法解析出查询哪个表的哪些字段,查询条件是啥;

再通过查询优化器处理,选择该sql最优的⼀套执⾏计划,然后执⾏器负责调⽤存储引擎的⼀系列接⼝,执⾏该计划⽽完成整个sql语句的执行,如下图所示:

InnoDB存储引擎-缓冲池中完成更新的基本操作

具体执⾏这些执⾏计划得要存储引擎来完成,比如⾸次更新users表中id=10的这条数据,缓冲池中⼀开始肯定没有该条数据的,

得要先从磁盘中将被更新数据的原始数据加载到缓冲池中(这⾥涉及到的innodb buffer暂时不讲)。

同时为了保证并发更新数据安全问题,会对这条数据先加锁,防⽌其他事务进⾏更新。

接着将更新前的值先备份写⼊到undo log中(便于事务回滚时取旧数据),⽐如update语句即存储被更新字段之前的值。

最后更新缓存⻚中的数据为最新的数据,⾄此就完成了在缓冲池中的执⾏流程,如下图所示: 

Redo Log和BinLog保证事务的可靠性

缓冲池中更新完数据后,需要将本次的更新信息顺序写到Redo Log⽇志以及Binlog⽇志中(此时信息还在内存中),

Redo Log刷盘策略由innodb_flush_log_at_trx_commit属性值来定,

0:不会写到磁盘
,宕机会导致已提交事务数据丢失

1:数据过来即写磁盘,做到教据零丢失但是效率会很低

2:写到os cache,每秒刷新一次到磁盘,宕机最多丢失1s的数据,速度够快

Binlog刷盘策略由sync_binlog属性来定,

1:强制刷盘;0:写入os cache。

⼀般我们为了保证数据不丢失会配置双1策略,

Redo Log落盘后,写Binlog落盘,再将Binlog的⽂件名、⽂件所在路径信息以及commit标记给同步顺序写到Redolog中(其中commit标记是否更新到Redo Log中,是判定事务是否成功提交的⼀个⽐较重要的标准),

Redo Log和BinLog分别在物理和逻辑层⾯为本次事务、提供数据上的⼀致性保障,如下图所示

 

 

将事务的操作持久化

前⾯⼀些列操作执⾏成功后,InnoDB存储引擎后台有⼀个IO线程,会在数据库压⼒的低峰期间时如凌晨时分,

将缓冲池中被事务更新、但还没来得及写到磁盘中的数据(脏数据,因为磁盘数据和内存数据已经不⼀致了)给刷到磁盘中,完成事务的持久化。

 

面试题解答

1.undo log和redo log了解过吗?它们的作⽤分别是什么?

undo log和redo log是mysql中InnoDB存储引擎的基本组成:

(1)undo log保存了事务执⾏前数据的值,以便于事务回滚时能回到事务执⾏前的数据版本,多次更

新会有undo log的版本链;

(2)redo log在物理层⾯上记录了事务操作的⼀系列信息,保证就算遇到mysql宕机等因素还没来得

及将数据刷到磁盘⾥,通过redo log也能恢复事务提交的数据。

2.redo log怎样保证事务不丢失的?

当⼀个事务提交成功后,虽然缓冲池中的数据不⼀定来得及⻢上落地到磁盘中,但是redo log记录的

事务信息持久化到磁盘中了、且含有commit标记,此时如果mysql宕机导致缓冲池中的、已经被事务更新

过的内存数据丢失了,此时在mysql重启时,将磁盘中的redo log中将事务变更信息给加载到缓冲池中,

保证事务信息不会丢失。或者redo log刷盘了,binlog写成功了,在重启时会⾃动给上commit标记,在重

放数据。

3.事务是先提交还是先刷盘?

事务先提交后刷盘;

1.Redo log刷盘成功->2.Binlog刷盘->3.BinLog名称和⽂件路径信息、commit标志写到Redo log

中,事务两阶段提交的⽅式来保证。

4.更新操作为什么不直接更新磁盘反⽽设计这样⼀个复杂的InnoDB存储引擎来完成?

直接更新磁盘是随机IO写,存在磁盘地址寻址操作,性能⾮常低,承载不了⾼并发场景;

⽽转换为InnoDB中,内存⾼速读写、redo log和undo log顺序写磁盘性能相对于随机IO写性能会⾼

的多,⽽这种性能上的提⾼⾜以抵消这种架构上带来的复杂,可在⼀定QPS内承载⾼并发场景。

 

往期文章推荐:

JVM专栏

消息中间件专栏

并发编程专栏

加载全部内容

相关教程
猜你喜欢
用户评论