一.逻辑存储结构
二.架构
1.内存结构
1.缓冲池(buffer_pool)
缓冲池buffer_pool:缓冲池是主内存中的一个区域,里面可缓存磁盘上经常操作的真实数据,在执行增删改查操作时,先操作缓冲池中的数据(若缓冲池没有数据,则从磁盘加载并缓存),然后再以一定频率刷新到磁盘,从而减少磁盘IO,加快处理速度。
缓冲池以page页为单位,底层采用链表数据结构管理page,根据状态可将page分为:
①free page:空闲page,未被使用
②clean page:被使用page,数据没有被修改过
③dirty page:脏页,被使用page,数据被修改过,数据与磁盘的数据不一致。
- 缓冲池 Buffer Pool 用于加速数据的访问和修改。
- 默认大小 128 M
- 缓存数据到内存,最大限度地减少磁盘 IO,加速 热点数据 的读和写
- 使用 **LRU 算法(最近最久未使用)**淘汰非热点数据页
- LRU:根据页数据的历史访问来淘汰数据,如果数据最近被访问过,那么将来访问的几率也更高,优先淘汰最近没有被访问到的数据
- Buffer Pool 中的数据以 页 为存储单位,数据结构是 单链表
- 对于 Buffer Pool 中数据的「查询」,InnoDB 直接读取返回;
- 对于 Buffer Pool 中数据的「修改」,InnoDB 直接在 Buffer Pool 中修改,并将修改写入 redo Log 中,当数据页被 LRU 算法淘汰时写入磁盘,若持久化前系统崩溃,则在重启后使用 redo Log 进行恢复。
2.修改缓冲区(change buffer)
Change Buffer 针对于非唯一二级索引页,在执行DML语句时,如果这些数据Page没有在Buffer Pool中,不会直接操作磁盘,而会将数据变更存在更改缓冲区(Change Buffer)中,在未来数据被读取中,再将数据合并恢复到Buffer Pool中,再将合并后的数据刷新到磁盘中。
Change Buffer存在的意义:
与聚集索引不同,二级索引是非唯一的,并且以相对随机的顺序插入二级索引,同样,删除和更新可能会影响索引树中不相邻的二级索引页,如果每一次都操作磁盘,会造成大量磁盘IO,有Change Buffer后,可在缓冲池进行合并处理,减少磁盘IO。
3.自适应hash索引(Adaptive Hash Index)
自适应hash索引用于优化对Buffer Pool数据的查询,InnoDB存储引擎会监控对表上各索引页的查询,如果观察到hash索引可以提升速度,则建立hash索引。
无需人工干预,是系统根据情况自动完成。
4.日志缓冲区(Log Buffer)
日志缓冲区用来保存要写入到磁盘中的log日志(redo log,undo log),默认大小为16MB,日志缓冲区的日志会定期刷新到磁盘中,如果需要更新、插入或删除许多行的事务,增加日志缓冲区的大小可节省磁盘IO。
2.磁盘结构
在磁盘中,InnoDB 存储引擎将 数据、索引、表结构和其他缓存信息等 存放的空间称为 表空间(Tablespace),它是 物理存储中的最高层,由 段Segment、区Extent、页Page、行Row 组成。
目前的表空间类别包括:
- 系统表空间(System Tablespace),关闭独立表空间,所有表数据和索引都会存入系统表空间
- 独立表空间(File-per-table Tablespace),开启独立表空间,每张表的数据都会存储到一个独立表空间
- 通用表空间(General Tablespace)
- 回滚表空间(Undo Tablespace)
- 临时表空间(The Temporary Tablespace)
双写缓冲区(doublewrite Buffer Files):InnoDB存储引擎将数据页从Buffer Pool刷新到磁盘前,先将数据写入该缓冲区,便于系统异常时恢复数据。
重做日志(redo Log):用来实现事务的持久性,分为重做日志缓冲(redo log buffer)以及重做日志文件(redo log),前者是在内存中,后者在磁盘中,当事务提交后会把所有修改信息都保存到该日志中,用于在刷新脏页到磁盘时,发生错误时,进行数据恢复使用。
3.后台线程
1.Master Thread
核心后台线程,负责调度其他线程,还负责将缓冲池中的数据异步刷新到磁盘中,保持数据的一致性,还包括脏页的刷新,合并插入缓存,undo页的回收
2.IO Thread
在InnoDB中大量使用了AIO来处理IO请求,这样可极大提高数据库的性能,IO thread主要负责这些IO请求的反馈。
3.Purge Thread
主要用于回收事务已提交的undo log,在事务提交后,undo log可能不用了,就通过它来回收
4.Page Cleaner Thread
协助Master Thread刷新脏页到磁盘的线程,可减轻Master Thread的工作压力,减少阻塞。
三.事务原理
1.redolog
重做日志记录的是事务提交数据页的物理修改,用来实现事务的持久性,分为重做日志缓冲和重做日志文件,前者在内存中,后者在磁盘中,当事务提交后把所有修改信息都存到改日志文件中,用于在刷新脏页到磁盘发生错误时,进行数据恢复使用。
2.undo log
回滚日志,用来实现事务的原子性。用于记录数据被修改前的信息,作用:①提供回滚②MVCC(多版本并发控制)
undo Log是记录逻辑日志(redo log记录物理日志),可认为当delete一条记录时,undo log会记录一条对应的insert记录,当update一条记录时,记录一条对应相反的update记录,当执行rollback时,就可以从redo log中的逻辑记录读取到相应的内容并进行回滚。
Undo Log销毁:undo log在事务执行时产生,事物提交时,并不会立即删除undo log,因为这些日志可能会用于MVCC
Undo log存储:undo log采用段的方式进行管理和记录,存放在前面介绍的rollback segment回滚段中,内部包含1024个undo log segment
redo Log 和undo Log保证了事务的一致性
三.MVCC
- 当前读:读取的是记录的最新版本,读取时需保证其他并发事务不能修改当前记录,会对读取的记录进行加锁,对于我们的日常操作,如:select...lock in share mode(共享锁),select...for update、update、insert、delete(排他锁)都是当前读。
- 快照读:简单的select(不加锁)就是快照读,快照读记录的是记录数据的可见版本,有可能是历史数据,不加锁,是非阻塞读。
- Read Committed:每次select 生成一个快照读。
- Repeatable Read:开启事务后的第一个select语句才是快照读的地方
- Serializable:快照读会退化为当前读
MVCC指维护一个数据的多个版本,使得读写操作没有冲突,快照读为MYSQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现,还需要依赖于数据库记录中的三个隐式字段、undo log日志、readView。
MVCC+锁保证了事务的隔离性
1.隐式字段
2.undolog版本链
当insert操作时,产生的undo log日志只在回滚时需要,在事务提交后可立即删除。
当update,delete操作时,产生的undo log日志不仅在回滚时需要,在快照读时也需要,不会立即被删除。
不同事务或相同事务对同一记录进行修改,会导致该记录的undolog生成一条记录版本链表,链表的头部是最新的旧记录,链表尾部是最早的旧记录。
3.readView
readView(读视图)是快照读SQL执行时MVCC提取数据的依据,记录并维护系统当前活跃的事务(未提交的)id,readView包含四个核心字段:
不同的隔离级别,生成的readView的时机不同:
- Read Committed:在事务中每一次执行快照读时生成ReadView。
- Repeatable Read:仅在事务中第一次执行快照读时生成ReadView,后续复用该ReadView。
4.原理分析
在RC级别下,事务中每一次执行快照读都会生成ReadView:
2.RR级别下,仅在食物中第一次执行快照读时生成ReadView,后续复用该ReadView: