​

概述

第一层 连接层

最上层为一些客户端和连接服务,主要完成一些类似于连接处理/授权认证.及相关的安全方案

connectors 连接
connection pool 连接池

第二层 业务逻辑处理层(服务层)

Management service & Utilties 安全,集群,容灾恢复等工具
SQL Interface SQL接口 表示接受用户的SQL命令，并且返回用户需要查询的结果，
Parser 解析器 解析指令,权限控制,{判断当前调用者是否有操作权限}
Optimzer 优化器 对SQL进行优化, 将输入SQL转换处理为优化器认为的最优SQL,(不一定是最优的)
Caches&Buffers 缓存

第三层 存储引擎层

存储引擎真正负责MySQL中数据的存储和提取,服务器通过API与存储引擎进行通信
可拔插式存储引擎,可根据需求使用相应引擎

第四层 文件存储层

主要是将数据存储在设备文件系统上,并完成与存储引擎的交互
​

​

优点

架构可以在不同场景中应用并发挥良好的作用,主要体现在存储引擎架构上,插件式的存储引擎架构将查询处理和其他任务系统以及数据的存储提取相分离.
​

​

​

​

​

​

存储引擎

MyISAM与InnoDB对比

对比项	MyISAM	InnoDB
主外键	不支持	支持
用户没有指定的话会自己找/生产一个隐藏列Row_id来充当默认主键）
事务	不支持	支持
(由于对行锁的支持进而支持事务)
行表锁	表锁,即使只操作一条记录也会锁住整个表,不适合高并发操作	行锁,操作时只锁某一行,不对其他行有影响.
适合高并发操作
缓存	只缓存索引,不缓存真实数据	同时缓存索引和真实数据,对内存要求较高,内存大小对性能有决定性影响
表空间	小	大
关注点	性能	事务
默认是否安装	Y	Y
索引	InnoDB是聚集索引，使用B+Tree作为索引结构，数据文件是和（主键）索引绑在一起的（表数据文件本身就是按B+Tree组织的一个索引结构），必须要有主键，通过主键索引效率很高。	MyISAM是非聚集索引，也是使用B+Tree作为索引结构，索引和数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

索引存储对比

数据文件对比

如何选择

1. 是否要支持事务，如果要请选择innodb，如果不需要可以考虑MyISAM；

​

2. 如果表中绝大多数都只是读查询，可以考虑MyISAM，如果既有读也有写，请使用InnoDB。

​

3. 系统奔溃后，MyISAM恢复起来更困难，能否接受；

​

4. MySQL5.5版本开始Innodb已经成为Mysql的默认引擎(之前是MyISAM)，说明其优势是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不会差。

​

​

SQL查询语句的执行过程

1.连接

首先,需要连接到具体的数据库上,这时就是连接器在与客户端建立连接,同时进行权限的管理,
客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。如果在连接被断开之后，客户端再次发送请求的话，就会收到错误提醒,这时候如果你要继续，就需要重连，然后再执行请求了。

2.查询缓存

执行逻辑的第二步是直接进入缓存查找,这时会将你输入的整个SQL语句当做一个key进行查找(不是解析SQL,而是直接用SQL语句本身来映射),命中后直接返回,不命中就继续向下执行
​

大多数情况下不建议使用缓存查询
原因:缓存的失效非常频繁,只要对一个表更新,那么这个表上的所有缓存都会被清空(而维护缓存需要消耗资源),除非是一张静态表,才适合使用缓存查询.
​

mysql 8.0之后缓存功能被彻底删除了

3.分析器

如果没有缓存被命中,则SQL就进入了分析阶段(缓存查询时是不分析SQL的),这时才是SQL语句真正执行的开始,
分析器首先会做"词法分析",将你的SQL中每个字符串,每个空格的意义识别出来.
接下来是进行"语法分析",语法分析器根据语法规则,判断SQL是否满足MySQL的语法,
经常遇到的you have an error in your SQL syntax 错误就是在分析器阶段产生的

4.优化器

经过了分析器后,MySQL已经知道你要做什么了,但是在开始执行之前,还需要经过优化器的处理
优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（ join ）
的时候，决定各个表的连接顺序。比如你执行下面这样的语句，这个语句是执行两个表的 join ：

mysql> select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20;

既可以先从表 t1 里面取出 c=10 的记录的 ID 值，再根据 ID 值关联到表 t2 ，再判断 t2 里面 d 的值是否等于20。
也可以先从表 t2 里面取出 d=20 的记录的 ID 值，再根据 ID 值关联到 t1 ，再判断 t1 里面 c 的值是否等于 10 。
这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。

[

](https://blog.csdn.net/qq_35642036/article/details/82820178)5.执行器
MySQL 通过分析器知道了你要做什么，通过优化器知道了该怎么做，于是就进入了执行器阶段，开始执行语句。
首先会对查询权限进行判断,判断一下你对这个表有没有执行查询的权限，如果没有，就会返回没有权限的错误

mysql> select * from T where ID=10;
ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'

若有权限,则打开表继续执行(在此处才正式打开表).之后执行器就会使用引擎提供的接口进行数据访问(不是执行器直接访问数据文件,而是使用引擎提供的接口)
比如我们这个例子中的表 T 中， ID 字段没有索引，那么执行器的执行流程是这样的：
​

1. 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是 10 ，如果不是则跳过，如果是则将这行存在结果集中；
   ​

2. 调用引擎接口取 “ 下一行 ” ，重复相同的判断逻辑，直到取到这个表的最后一行。
   ​

3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。
   ​

至此，这个语句就执行完成了。
​

SQL更新语句的执行过程(日志系统)

流程

更新操作同样也会走查询操作的步骤,不过略有不同
​

在缓存阶段,更新语句将会清空该表的缓存.
​

解析器解析到这是一个更新语句,优化器确定了使用某个索引,执行器负责执行,调用存储引擎接口查找到这一行,然后更新这一行.
​

日志系统

与查询流程不一样的是，更新流程还涉及两个重要的日志模块, redo log(重做日志)和 binlog(归档日志)

redo log（重做日志）

innodb引擎在更新一条语句的时候不是直接将修改后的值直接写入磁盘(这样每次io会消耗大量时间),
所以每次更新操作后,MySQL会将更新记录写到redo log日志文件中,并更新内存(而不是磁盘),这个时候语句相当于已经执行完成了.在之后的系统空闲时间再进日志中的记录写入磁盘.
​

如果更新数量较少,那么MySQL会等待系统空闲再更新,但是如果redo log被写满了,MySQL就会先处理日志中最前面的更新(写入磁盘),腾出空间

redo log的写入是从头开始写，写到末尾就又回到开头循环写
write pos是当前记录的位置，一边写一边后移，写到第3号文件末尾后就回到0号文件开头。
checkpoint是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。

crash-safe

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个 能力称为crash-safe。
数据库异常后,磁盘数据丢失了,但是MySQL依然可以通过日志文件系统恢复到异常前状态

binlog(归档日志)

redo log 是InnoDB自己特有的日志系统,而MySQL并不只有这一中存储引擎,所以MySQL需要一个能服务整个系统的日志文件系统
所以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是逻辑日志,记录的是每条SQL语句的原始逻辑 ,比如“给ID=2这一行的c字段加1 ”。
3. redo log是循环写的,binlog是追加写的,不会覆盖以前的日志.

​

整体执行流程

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

1. 执行器先找引擎取ID=2这一行。ID是主键，引擎直接用树搜索找到这一行。如果ID=2这一
   行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然
   后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上1，比如原来是N，现在就是N+1，得到新的一行
   数据，再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处
   于prepare状态。然后告知执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的binlog，并把binlog写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交（commit）状态，更
   新完成。

两阶段提交

在日志文件阶段进行了两次提交(prepare和commit)

​

目的就是为了保证两个日志文件完全一样
如果没有两阶段提交,必然有一个日志文件先完成,有一个后完成,如果两个日志完成间隙系统故障,那么两个日志文件的内容就发生了不同.
两阶段提交出现后,先写redo log将其第一次提交(这时此条语句并没有生效),再写binlog,写完后在将redo log commit,保证同时生效(出现不一致大概率是发生在一个文件写完,而写另一个文件的时候,相比于写文件,提交的时间可以忽略不计)

怎样让数据库恢复到半个月内任意一秒的状态？

• 首先，找到最近的一次全量备份，如果你运气好，可能就是昨天晚上的一个备份，从这个备 份恢复到临时库；
• 然后，从备份的时间点开始，将备份的binlog依次取出来，重放到中午误删表之前的那个时 刻。