【MySQL数据库】存储引擎的详细解析和方式

一、MySQL体系结构

img

1. 连接层

最上层是一些客户端和链接服务,主要完成一些类似于连接处理、授权认证、及相关的安全方案。服务器也会为安全接入的每个客户
  端验证它所具有的操作权限。

2. 服务层

第二层架构主要完成大多数的核心服务功能,如SQL接口,并完成缓存的查询, SQL 的分析和优化,部分内置函数的执行。所有跨存
  储引擎的功能也在这一层实现, 如过程、函数等。

3. 引擎层

存储引擎真正的负责了MySQL中数据的存储和提取,服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能,这样我们可以根据自己的需要,来选取合适的存储引擎。

4. 存储层

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

二、存储引擎介绍

1. 查看存储引擎

存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的,而不是基于库的,所以存储引擎也可被称为表类型。

mysql5.5版本之后默认的引擎是InnoDB,可以根据sql语句查看建表语句

#查看建表语句  默认存储引擎是InnoDB
show create table account;

img

2. 建表时指定存储引擎

create table 表名(
    字段1 字段1类型,
    字段2 字段2类型
)engine = innodb;

默认引擎就是innodb也可以省略不写或者设置为其他存储引擎

3. 查询当前数据库支持的存储引擎

show engines;

img

三、存储引擎特点

1. InnoDB

InnoDB是一种兼顾高可靠性和高性能的通用存储引擎,在MySQL 5.5之后, InnoDB是默认的MySQL存储引擎。

特点:

DML(增删改)操作遵循ACID模型,支持事务
    行级锁,提高并发访问性能
    支持外键FOREIGN KEY约束,保证数据的完整性和正确性

文件:

xxx.ibd: xxx代表的是表名,innoDB引擎的每张表都会对应这样一个表空间文件, 存储该表的表结构(frm、 sdi)、数据和索引。
    参数: innodb_ file_per_table 代表每一张表对应一个表空间

InnoDB逻辑结构:

img

2. MyISAM

MylSAM是MySQL早期的默认存储引擎。

特点:

不支持事务,不支持外键
    支持表锁,不支持行锁
    访问速度快

文件:

xxx.sdi: 存储表结构信息
    xxx.MYD: 存储数据
    xxx.MYI: 存储索引

3. Memory

Memory引擎的表数据是存储在内存中的,由于受到硬件问题、或断电问题的影响,只能将这些表作为临时表或缓存使用。

特点:

内存存放
    hash索引(默认)

文件:

xxx.sdi:存储表结构信息

4. 三种存储引擎的区别

img

四、存储引擎的选择

在选择存储引擎时,应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统,还可以根据实际情况选择多种存储引擎进行组合。

1. InnoDB

是Mysq|的默认存储引擎,支持事务、外键。如果应用对事务的完整性有比较高的要求,在并发条件下要求数据的一致性,数据操作除了插入和查询之外,还包含很多的更新、删除操作,那么InnoDB存储引擎是比较合适的选择。

2. MyISAM

如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性、并发性要求不是很高,那么选择这个存储引擎是非常合适的。(此类场景的使用被MongoDB取代)

3. MEMORY

将所有数据保存在内存中,访问速度快,通常用于临时表及缓存。MEMORY的缺陷就是对表的大小有限制,太大的表无法缓存在内存中,而且无法保障数据的安全性。(此类场景更多的使用被Redis取代)

五、InnoDB

1. 逻辑存储结构

img

2.InnoDB架构

MySQL5.5版本开始,默认使用InnoDB存储引擎,它擅长事务处理,具有崩溃恢复特性,在日常开发中使用非常广泛。下面是InnoDB架构图,左侧为内存结构,右侧为磁盘结构。

img

內存架构——缓冲池

img

內存结构——更改缓冲区(8.0之后引入)

img

內存结构——自适应Hash索引

img

內存结构—日志缓冲区

img

磁盘缓冲区

img

img

img

架构——后台线程

InnoDB后天线程有四类:

1. Master Thread
   核心后台线程,负责调度其他线程,还负责将缓冲池中的数据异步刷新到磁盘中,保持数据的一致性,还包括脏页的刷新、合并插入缓存、undo页的回收。

2. IO Thread

在InnoDB存储引擎中大量使用了AIO来处理IO请求,这样可以极大地提高数据库的性能,而IO Thread主要负责这些IO请求的回调。

img

3. Purge Thread

主要用于回收事务已经提交了的undo log,在事务提交之后,undo log可能不用了,就用它来回收。.

4. Page Cleaner Thread

协助Master Thread刷新脏页到磁盘的线程,它可以减轻Master Thread的工作压力,减少阻塞。

3. 事务原理

事务的四大特性:原子性、一致性、隔离性、持久性

原子性、一致性、持久性:是由InnoDB存储引擎底层存储的两份日志来保障的。redo log undo log

隔离性:由InnoDB存储引擎底层的机制,MVCC

redo log

重做日志,记录的是事务提交时数据页的物理修改,是用来实现事务的持久性
  该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log file) ,前者是在内存中,后者在磁盘中。当事务
  提交之后会把所有修改信息都存到该日志文件中,用于在刷新脏页到磁盘,发生错误时,进行数据恢复使用。

undo log

回滚日志,用于记录数据被修改前的信息,作用包含两个:提供回滚和MVCC(多版本并发控制)。
  undo log和redo log记录物理日志不一样,它是逻辑日志。可以认为当delete一条记录时, undo log中会记录一条对应的insert记录, 反之
  亦然,当update一条记录时,它记录一条对应相反的update记录。当执行rollback时,就可以从undo log中的逻辑记录读取到相应的内容并进行回滚
  Undo log销毁: undo log在事务执行时产生,事务提交时,并不会立即删除undo log,因为这些日志可能还用于MVCC。
  Undo log存储: undo log采用段的方式进行管理和记录,存放在前面介绍的rollback segment回滚段中,内部包含1024个undo log segment。

4. MVCC

当前读

读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁。对于我们日常的操作,如:select … lock in share mode(共享锁),select … for update、update、 insert、 delete(排他锁)都是 -种当前读。

快照读

简单的select (不加锁)就是快照读,快照读,读取的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。
   Read Committed:每次select, 都生成一个快照读。
   Repeatable Read:开启事务后第一个select语句才是快照读的地方。
   Serializable:快照读会退化为当前读。

MVCC

全称Multi-Version Concurrency Control,多版本并发控制。指维护一个数据的多 个版本,使得读写操作没有冲突,快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现,还需要依赖于数据库记录中的三个隐式字段undo log日志readView

MVCC——实现原理

记录中的隐藏字段

DB_TRX_ID:最近修改事务ID,记录插入这条记录或最后一-次修改该记录的事务ID。
  DB_ ROLL_PTR:回滚指针,指向这条记录的上一个版本,用于配合undo log,指向上一个版本。
  DB_ROW_ID:隐藏主键,如果表结构没有指定主键,将会生成该隐藏字段。

undo log版本链

img

不同事务或相同事务对同一条记录进行修改,会导致该记录的undolog生成一条记录版本链表, 链表的头部是最新的旧记录,链表尾部是最早的旧记录

readview

ReadView (读视图)是快照读SQL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的) id。
  ReadView中包含了四个核心字段:

img

img

不同的隔离级别,生成ReadView的时机不同:
 READ COMMITTED :在事务中每一次执行快照读时生 成ReadView。
 REPEATABLE READ:仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序源日志

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值