逻辑存储结构
逻辑存储结构图
表空间
表空间文件在Linux下存放在 /var/lib/mysql文件中的 xxx.ibd 文件就是表空间文件
表空间文件用来存储,记录,索引等数据。
段
段分为,数据段(Leaf node segment) ,索引段(Non-leaf node segment),回滚段(Rollback segment),InnoDB是索引组织表,数据段就是B+树的叶子节点,索引段就是非叶子节点,段用来管理Extend(区)。
一个段相当于一张表
区
区是表空间的单元结构,每个区大小为1M,默认情况下InnoDB存储引擎页大小为16k,一个区一共16个连续的页。
页
页,是InnoDB存储引擎磁盘管理的最小单元。
每个区默认16KB,为了保证页的连续性,InnoDB存储引擎每次从磁盘申请4到5个区。
行
行指的是InnoDB存储的数据
表结构中俩个隐藏字段
Trx_id:最后一次操作事务的id
Roll pointer:指针,指向增删改之前的数据,可以拿这个找到修改之前的数据。
架构
MySQL5.5版本后,默认使用InoDB存储引擎。
它擅长事务处理,具有崩溃恢复性特性!
下图为InnoDB架构图,左边为内存结构,右边为磁盘结构。
内存结构
Buffer Pool(缓冲池)
缓冲池是主内存的一个区域,里面可以缓存磁盘上经常操作的真实数据。
在执行增删改查操作的时候,先操作缓存池中的数据(如果没有,从磁盘加载并且缓存)
然后以一定频率刷新到磁盘,从而减少磁盘IO,加快处理速度
在缓存池中有一块一块的,这个是页。
缓存池以页为单位,底层采用链表数据结构管理Page。
根据状态将Page分为三类:
- free page:空闲页,未被使用的页。
- clean page :被使用的页,数据没有被修改过。
- dirty page :脏页,被使用的页,页中数据和磁盘中数据不一致。
Change Buffer(更改缓存区)
介绍
更改缓存区,主要针对非唯一的二级索引。
在执行DML语句时,如果这些数据页不在Buffer Poor中,不会直接操作磁盘,而是将数据变更在更改缓存区Change Buffer中。
在未来数据被读取的时候,再将数据合并恢复到Buffer Pool中,再将合并后的数据刷新到磁盘中。
意义
和聚集索引不同,二级索引是非唯一的!
并且二级索引以相对随机的顺序插入。
同样的删除和更新可能会影响索引树中不相邻的二级索引页,如果每一次都操作磁盘,会造成大量磁盘IO。
有了ChangeBuffer后,我们可以在缓冲池中进行合并处理减少磁盘IO
Log Buffer(日志缓存区)
日志缓存区,用来保存要写入磁盘中的log日志数据(redo log 、undo log)。
默认大小16MB,日志缓存区的日志会定期刷新到磁盘中。如果需要更新、插入、或删除多行的事务,增加日志缓存区大小可以节约磁盘IO
在系统变量中设置即可
关键字:
innodb_log_buffer_size缓存区大小
innodb_flush_log_at_trx_commit日志刷新到磁盘的时机
1代表的是日志在每次事务提交时写入并刷新到磁盘
0代表每秒将日志写入并刷新到磁盘一次
2代表日志在每次事务提交后写入,并且每秒刷新到磁盘一次
Adaaptive Hash index(自适应哈希索引)
自适应哈希索引,用于优化Buffer Pool数据的查询。
InnoDB存储引擎会监控表上各索引页的查询,如果观察到hash索引可以提高速度,就会建立hash索引。
这个叫自适应哈希索引
可以在系统变量中查询是否开启自适应哈希索引
关键字是 adaptive_hash_index
磁盘结构
System Tablespace(系统表空间)
系统表空间是change Buffer的存放区域。
关键字:innodb_data_file_path
系统表空间存放路径
File-Per-Table Tablespaces
存放每个表的独立表空间
默认是开启的–>开启后代表每一张表都会生成对应的表空间文件。
xxx.ibd结尾的文件都是表的表空间文件
查看变量 innodb_file_per_table看是开的还是关的
里面存放了表结构,表数据,索引
General Tablespaces(通用表空间)
通用表空间,需要手动通过
create tablespace 表空间名 add datafile '表空间对应的磁盘文件.ibd' engine=innodb;
创建通用表空间。
在创建表的时候可以指定该表空间
create table 表名(字段....)engine=存储引擎 tablespace 表空间名;
Undo Tablespaces(撤销表空间)
撤销表空间,MYSQL实例在初始化的时候会自动创建俩个默认的undo表空间(初始大小16M)用来存放undo log日志
默认叫 undo_001和undo_002
Temporary Tablespaces(临时表空间)
用来存储用户创建的临时表。
Doublewrite Buffer Files(双写缓冲区)
双写缓冲区,innoDB存储引擎会将数据页冲Buffer Pool刷新到磁盘前,先将数据页写入双写缓冲区文件中,便于系统异常时恢复数据。
双写缓冲区文件:xxx.dblwr
Redo Log(重做日志)
用来实现事务的持久性。
该日志文件由俩个部分组成:重做日志缓冲区(redo log buffer)和重做日志文件(redo log)
重做日志缓冲区:是在内存中
重做日志文件:是在磁盘在
事务提交后会把所有修改的信息存放在该日志中,用于刷新脏页到磁盘,发生错误时,进行数据恢复使用
以循环的方式写入重做文件,涉及到俩个文件:ib_logfile0和ib_logfile1
后台线程
作用:将Innodb缓冲池的数据在合适的时机刷新到磁盘文件中。
分为四类:
Master Thread
核心后台线程,负责调度其他线程。还负责将缓冲池中的数据异步刷新到磁盘中,保持数据的一致性。
还包括,脏页的刷新,合并插入缓冲,undo页的回收
IO Thread
在InoDB存储引擎中大量使用了AIO来处理IO请求,这样可以极大提高数据库性能,IO Thread主要负责以下IO请求的回调
线程类型 默认个数 责任 Read thread 4 负责读操作 write thread 4 负责写操作 Log thread 1 负责将日志缓冲区刷新到磁盘 Insert buffer thread 1 负责将写缓冲区内容刷新到磁盘 关于AIO(异步IO)和IO(同步IO)
同步就是在发出一个功能调用时,在没有得到结果之前,该调用就不返回。也就是必须一件一件事做,等前一件事做完了才能做下一件事。
异步的概念和同步相对。当一个异步过程调用发出后,调用者不能立刻得到结果(在此期间,调用者可以去干一些别的事情)。实际处理这个调用的部件在完成后,通过状态、通知和回调。
Purge Thread
主要用于回收事务已经提交的undo log,在事务提交之后,undo log可能不需要了,就用这个来回收。
Page Cleaner Thread
协助Master Thread刷新脏页到磁盘的线程,他可以减轻Master Thread的工作压力,减少阻塞。
整个流程
在增删改查的时候,会操作内存结构区域,如果里面没有数据就从。磁盘结构中加载,然后进行操作。
最后在特定时间会自动从内存结构中刷新到磁盘中。在磁盘中进行持久化保存下来
事务原理事务
事务是一组操作的集合,它是一个不可分割的工作单位,事务会把所有操作作为一个整体一起向系统提交撤销操作请求。
这些操作要么同时成功要么同时失败。
事务的四大性质
原子性
事务是不可分割的最小操作单元,要么全部成功,要么全部失败。
一致性
事务完成时,必须使所有的数据保持一致性。
隔离性
数据库系统提高隔离机制,保证事务在不受外部并发操作影响的独立环境运行。
持久性
事务一旦提交或回滚,他对数据库的数据改变就是永久的。
事务的原理
事务的原子性,一致性,持久性都是由redo log和undo log实现的
事务的隔离性是由 锁机制和MVCC实现的。
redo log
重做日志,记录的是事务提交时数据页的物理修改,用来实现事务的持久性。
该日志文件由俩部分组成:
重做日志缓冲(redo log buffer)
在内存中
重做日志文件(redo log file)
在磁盘中
当事务提交后会把所有修改信息都存放到该日志文件中,用于在刷新脏页到磁盘中,发生错误时,进行数据的恢复。
大概流程:
客户端A对innoDB存储引擎的表进行增删改事务操作
先访问内存结构中的缓冲池,如果增删改数据在其中不存在,
就会从磁盘中读取数据再刷新到缓冲池(这个数据必须是唯一索引,否则会先进入到更改缓冲区)
在缓冲池中变成脏页,并记录在redolog buffer中,后直接刷新到磁盘中
如果脏页在一段时间后刷新到磁盘中报错了,可以通过redo log进行恢复。
使用redo log直接刷新到磁盘结构的好处
事务一般是一组多条的增删改查操作,故事务提交的时候会随机的操作多条的记录。
这些记录会操作多条数据页,这样会产生大量的随机磁盘IO
而直接将redo log文件异步刷新到磁盘io中,由于它是日志文件,日志文件都是追加的,此时是顺序磁盘IO,这样会节约大量的磁盘IO
这种机制叫WAL(Write-Ahead Logging)(先写日志)
然后过一段时间脏页日志才会刷新到磁盘中。
故俩份日志是循环清理的
事务的redo log日志是为了解决脏页刷新到磁盘出错时进行数据的恢复使用的,用来保证数据的持久性
undo log
undo log日志是用来保证事务的原子性的。
undo log也叫回滚日志,用于记录数据被修改前的信息,作用为:提供回滚和MVCC
redo log记录的是物理日志!
undo log记录的是逻辑日志,可以认为当执行delete 一条记录时,undo log中会记录一条对应的insert记录,反之同理。
当执行rollback时,就可以从undo log中的逻辑记录读取到对应内容,从而进行回滚。
Undo log销毁
undo log在事务执行时产生,事务提交时,并不会马上删除undo log,因为这些日志可能还用于MVCC
Undo log存储
undo log采用,段的方式进行管理和记录,存放在前面介绍的rollback segment回滚中,内部包含了1024个undo log segment
这个段是逻辑存储结构的段哦~
MVCC(多版本并发控制)(高频面试题)MVCC的几个基本概念当前读
我们读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁,
对于我们日常的操作,如:select…lock in share mode(共享锁),select…for update,update,insert,delete(排他锁)
都是一种当前读。
案例:
在RR的隔离级别下
- 事务A进行查询操作,事务B进行更新操作并提交事务
- 事务A使用当前读select…此时读取的是事务B更新之前的数据(原因是隔离级别)
- 事务A使用select…lock in share mode(当前读)此时读取的是事务B更新之后的数据。
快照读
简单的select(不加锁)就是快照读,读取的是记录数据的可见版本,可能是历史数据,不加锁是非阻塞读。
- Read Committed隔离级别:每次select都生成一个快照读
- Repeatable Read隔离级别:开启事务后第一个select语句才是快照读的地方(后续查的就是这个快照数据)
- Serializable隔离级别:快照读会退化为当前读
MVCC介绍
全称Multi-Version Concurrency Control 多版本并发控制。
指的是维护一个数据的多个版本,使得读写操作没有冲突。
快照读为MYSQL实现MVCC提供了一个非阻塞读功能,MVCC的具体实现,还需要依赖,数据库的三个隐藏字段、
undo log日志、readView
MVCC-实现原理记录中的隐藏字段
当我们创建了表除了自己本身创建的字段,innoDB引擎会自动给我们创建三个字段
分别是:
- DB_TRX_ID
- DB_ROLL_PTR
- DB_ROW_ID
隐藏字段 | 含义 |
---|---|
DB_TRX_ID | 最近修改事务ID,记录插入这条记录或者最后一次修改该记录的ID(事务id) |
DB_ROLL_PTR | 回滚指针,指向这条记录的上一个版本,用于配合undo log指向上一个版本 |
DB_ROW_ID | 隐藏主键,如果表结构没有指定主键,就会生成该隐藏字段 |
可以查看表空间文件内容来查看隐藏字段信息
事务id是自增的!
在MYSQL中提供了一个命令来查看表空间文件的记录信息
ibd2sdi xxx.ibd
undo log版本链
回滚日志,在insert、update、delete的时候产生的便于数据回滚的日志
当insert的时候,产生的undo log日志只在回滚时需要,在事务提交后,可被立即删除。
当update、delete的时候,产生的undo log日志不只是回滚时需要,在快照读时也需要,不会被立即删除。
Undo log版本链
不同事务或相同事务对同一条记录进行修改,会导致该记录的undo log生成一个记录的版本链表,链表的头部是最新的旧记录,链表的尾部是最早的旧记录。
执行顺序:
从上到下代表执行顺序。在同一行代表同一时间执行。
ReadView(读视图)
ReadView(读视图)是快照读SQL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id
ReadView中包含了四个核心字段
字段 | 含义 |
---|---|
m_ids | 当前活跃的事务id集合 |
min_trx_id | 最小活跃的事务ID |
max_trx_id | 预分配事务ID,当前最大事务ID+1(因为事务ID是自增的) |
creator_trx_id | ReadView创建者的事务ID |
版本链数据访问规则
trx_id代表的是当前事务的id
用这个id和ReadView的四个核心字段进行比对
trx_id == creator_trx_id可以访问该版本这个条件成立代表数据是当前这个事务更改的
trx_id < min_trx_id 可以访问该版本 这个条件成立,说明数据已提交
trx_id > max_trx_id 不可以访问该版本 这个条件成立,说明事务是在ReadView生成之后才开启的
min_trx_id <= trx_id <= max_trx_id 如果trx_id不在m_ids中,就可以访问该版本
这个条件成立,说明数据已经提交。
根据隔离级别的不同ReadView生成时机不同
在Read Committed隔离级别下
在事务第一次执行快照读时都生成一个Read view
在Repeatable read隔离级别下
在事务第一次执行快照读时生成,后续复用这个Read view
在RC隔离级别下,版本链访问原理分析
在事务第一次执行快照读时都生成一个Read view
第一个快照读,读取情况
这个快照读,根据规则,读取的是0x00002这个地址的数据,对应着事务2修改后的数据内容。
第二个快照读,读取情况
这个快照读,根据规则读取到的是,0x00003地址的数据内容,就是事务3修改后的数据。
在RR隔离级别下,版本链访问原理分析
在RR隔离级别下,只有事务在第一次执行快照读的时候生成ReadView,后续复用这个ReadView
具体的和RC规则一致,不重复讲解。
总结
隐藏字段+Undo log版本链+ReadView组成MVCC
MVCC+锁构成事务的隔离机制
事务的一致性由Redo log和undo log共同保证