MySQL 基本架构 分析器 执行器 redo log binlog

MySQL 基本架构 分析器 执行器 redo log binlog_第1张图片

MySQL主要由连接器、分析器、优化器、执行器组成,此外还有存储引擎

其中上半部分属于Server层,是数据库的核心层,承担了视图、触发器、内置函数等关键功能

下半部分属于存储引擎部分,一般使用的是INNODB

一条sql语句执行要经过什么步骤?

首先进行词法分析和语法分析,这是在分析器内完成的,词法分析检查语句是否有错以及检查该表或列字段是否存在。然后,进行语句的优化,优化器是在表里面有多个索引的时候,决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序。最后就是执行了,注意执行的开始要检查是否有权限,然后调用存储引擎去执行语句。

MySQL日志:redo log binlog

redo log:引擎层日志,主要是记录数据库的更新操作,数据库的更新可以理解为两步:第一步将操作语句记录在redo log日志当中,然后等系统空闲的时候去分批执行。这也叫做WAL,WAL的全称是Write-Ahead Logging,它的关键点就是先写日志,再写磁盘。

为什么要先写日志,再执行语句呢?这是由于我们要实现crash-safe,InnoDB引擎通过日志就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,都保留在redo log当中,进而可以通过redo log来恢复数据库,这个能力称为crash-safe

binlog:server层日志,它的由来:最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM,但是MyISAM没有crash-safe的能力,binlog日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的,既然只依靠binlog是没有crash-safe能力的,所以InnoDB使用另外一套日志系统——也就是redo log来实现crash-safe能力。最核心的作用在于归档,而且binlog不会循环写,而是追加写,因此永远不会覆盖之前的日志!

不同点:

  1. redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。

  2. redo log是物理日志,记录的是“在某个数据页上做了什么修改”;binlog是逻辑日志,记录的是这个语句的原始逻辑,比如“给ID=2这一行的c字段加1 ”。

  3. redo log是循环写的,空间固定会用完;binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。

MySQL 基本架构 分析器 执行器 redo log binlog_第2张图片

语句执行流程,例如一个更新语句

注意到最下面的两状态提交!

先是redo log prepared 然后 binlog后 再redo log commit

那么为什么要有两个日志呢?binlog能不能不要呢?

我的理解分以下几点:

1、redo log只是innodb引擎层特有的,所以你换别的引擎之后就没有redo log了,所以binlog是必要的。

2、binlog有归档的功能,而redo log不具备

你可能感兴趣的:(服务器,运维,数据库架构,mysql,数据库)