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

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文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

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

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

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

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

我的理解分以下几点：

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

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