最通俗易懂的MySQL进阶Innodb详解

MySQL进阶Innodb详解

innodb逻辑存储结构

表空间包含段，段包含区，区包含页，页包含行

表空间
在数据库文件中都有一个或多个ibd文件，ibd文件相当于表空间，主要用于存储索引，记录等数据。

段
段，分为数据段,索引段、回滚段，InnoDB是索引组织表，数据段就是B+树的叶子节点，索引段即为B+树的非叶子节点。段用来管理多个Extent(区)。

区
区是由连续的页组成的，任何情况下一个区的大小为1M，一个页默认大小为16k，一个区就是由64个连续的页，

页
页是innodb管理存储引擎的最小存储单元。为了保证页中存储数据的连续性，会向磁盘申请4-5个区。

行
InnoDB存储引擎是面向行的，也就是说数据的存放按行进行存放

innodb架构

左侧内存结构

Buffer pool
当执行增删改操作时，先是修改缓冲区页中的数据，以一定的频率刷到磁盘当中，缓冲区的页改变之后并不是直接刷新到磁盘中去，会是以checkpoint机制来刷新到磁盘中去。当执行读操作时，会首先读取缓冲池里的数据，而不是直接读取磁盘，如果没有命中，将会从磁盘中读取，再存到缓冲区中。这样做的原因是减少磁盘的io，提高性能。
缓冲区中由三种页：free page指申请了空间还没被使用的页；clean page指有数据但没有被修改过的页；dirty page指脏页，产生了数据不一致，也就是缓冲区中的页数据被修改了，而磁盘的页还没有被修改；

change buffer
当进行增删改操作时，在buffer pool中没有对应的数据时，增删改的数据会存储到change buffer中，不会直接修改磁盘，而是当再去读取该数据时，会将有一个后台线程将change buffer 合并到buffer pool 中去，同时将增删改的数据将会刷新到磁盘中，这样做有效减少了磁盘的io，提高性能。

Adaptive Hash Index
自适应hash索引，用于优化对Buffer Pool数据的查询。InnoDB存储引擎会监控对表上各索引页的查询，如果观察到hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。

Log buffer
日志缓冲区，用来保存要写入到磁盘中的log日志数据（redo log 、 undo log)，默认大小为16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘I/O。

右侧磁盘结构

System Tablespace
系统表空间是更改缓冲区（change buffer）的存储区域。如果表是在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典,undolog等)

File-Per-Table Tablespaces
每个表的文件表空间包含单个InnoDB表的数据和索引，并存储在文件系统上的单个数据文件中

GeneralTablespaces
通用表空间，需要通过CREATE TABLESPACE语法创建通用表空间，在创建表时，可以指定该表空间

Undo Tablespaces
撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间〈初始大小16M)，用于存储undo log日志。

Temporary Tablespaces
InnoDB使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。

Doublewrite Buffer Files
双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中,便于系统异常时恢复数据。

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

事务原理

事务是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失败。

特性
原子性:事务是不可分割的最小操作单元，要么全部成功，要么全部失败。
一致性:事务完成时，必须使所有的数据都保持一致状态。
隔离性︰数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。
持久性:事务一旦提交或回滚，它对数据库中的数据的改变就是永久的。

redoLog
redoLog确保事务的持久性
当客户端进行多个增删改操作作为事务时，首先会操作内存结构中的缓冲区，看是否命中，如果没有命中，后台线程将同步磁盘的数据到缓冲区中，再操作，操作的页就变为了脏页，这同时在内存结构中修改的数据也会存储到redolog 缓冲区中，在事务提交commit之后，同步刷新redolog缓冲区，在磁盘结构中产生一个redolog重做日志文件，之后将修改的数据页刷新到磁盘中时，即使刷新脏页到磁盘时,发生错误时,可以通过redolog日志文件来数据恢复，确保事务的持久性。

undoLog
undoLog确保事务的原子性
回滚日志，用于记录数据被修改前的信息，作用包含两个:提供回滚和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采用段的方式进行管理和记录，存放在前面介绍的 rolback segment 回滚段中，内部包含1024个undo logsegment。

MVCC

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

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

隐藏字段
当创建一张表时，在自己定义的字段显现表示出来的同时，还有三个隐藏字段

undoLog
回滚日志，在insert、update.delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除。
而update、delete的时候，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除。
undolog版本链
当多个事务并发update、delete操作一条记录时，首先将原始数据存储到undolog中去，再将记录的隐藏字段的DB_TRX_ID(事务id)修改成当前事务id，回滚指针指向undolog存储的记录，后面再有事务修改提交，逐一的操作，形成一条版本链。

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

readview的可见性判断

1.trx_id == creator_trx_id
表示版本链中的事务id等于当前事务的id，如果成立则显示该版本的数据，也就是说这个数据是自己事务生成的，自己当然能看到自己所生成的数据

2.trx_id< min_trx_id
表示版本链的事务id小于最小活跃事务id，如果成立则显示该版本的数据，也就是说该数据是在当前事务启之前就已经存在了的,比如第一个事务修改数据，产生了第一个版本链，并且也已经提交，事务二去干其他的事情，事务三查询该数据，产生了readview，此时就会取第一个事务的数据，因为符合这个条件

3.trx_id > =max_trx_id
表示版本链的事务id大于最大活跃事务加一，如果成立则不显示该版本的数据，也就是说该数据是在当前read view 创建之后才产生的，所以数据不显示。

4.trx_id <max_trx_id
表示版本链的事务id小于最大活跃事务加一，如果成立则进入下一条判断trx_id 是否在活跃事务的集合里，如果不存在则说明read view产生的时候事务已经commit了，这种情况数据则可以显示。如果存在则说明Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的。

读已提交级别
在读已提交级别下的MySQL数据库，则会在每一次读操作时，都会产生一个readview。

可重复读级别
在可重复读级别下的MySQL数据库，则会在当前事务的第一次读操作时，产生一个readview，之后的读操作将复用这个readview，不再重新产生。

参考视频：https://www.bilibili.com/video/BV1Kr4y1i7ru?p=145&spm_id_from=333.880.my_history.page.click