MySQL学习笔记7【InnoDB】

Innodb

1. 架构

1.1 内存部分

buffer pool

缓冲池是主存中的第一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删查改操作时，先操作缓冲池中的数据，然后以一定频率刷新到磁盘，这样操作明显提升了速度。

缓冲池以page为单位，底层采取链表的数据结构管理page，这一点和xv6是一模一样的，根据状态，分为三类：

空闲页free page
干净页clean page，分配之后没有被修改过
脏页dirty page，数据被修改过，与磁盘中的数据不一致

change buffer

更改缓冲区，字面意思，主要针对于二级索引页，当我们在buffer pool执行数据变更操作(DML)的时候，如果没有找到这个数据，并不会直接读取磁盘数据，而是将其写入到change buffer，等未来读取数据的时候，直接将数据合并，恢复到buffer pool中，再将数据刷新到磁盘中，由于二级索引页插入删除相对随机，所以如果每次写入都会进行磁盘IO的话，性能太差，而使用change buffer，就减少了磁盘IO，提高了读写效率。

自适应哈希

自适应哈希索引，我们的InnoDB引擎默认是B+树索引，相对于哈希表慢一点，但是哈希表不支持范围查询，所以InnoDB为了提高查询效率，为buffer pool添加了一个自适应哈希索引，我们的InnoDB引擎会自己监控各个索引页上的索引，如果观察到hash索引可以提升查询速度，就会建立哈希索引，这个过程无需人工干预，但是我们需要知道这个参数是adaptive_hash_index，默认开启。

log buffer

保存要写入到磁盘中的两份日志：redo log和undo log，默认大小16M，会定期刷新到磁盘，如果更新插入较频繁，增加缓冲区大小可以减少磁盘IO，参数：

innodb_log_buffer：缓冲区大小。
innodb_flush_log_trx_commit：刷新到磁盘的时机。
1：每次事务提交写入
0：每秒写入
2：两者结合

1.2 磁盘部分

系统表空间

主要处理非主键非唯一的二级索引的更改缓冲区，也就是change buffer，当然，这个和内存中的change buffer不一样，它主要用来存储我们的在真正写入表空间的变更操作，为啥不直接写入表空间？，原因是这样可以进一步避免频繁的磁盘IO，我们缓存的是变更操作，而不是整页的数据，并且在磁盘上，可以缓存大量变更。

文件表空间

我们建立的每一张表都有一个独立的表空间，文件表空间都包含单个InnoDB表的结构，数据和索引，并且存储在文件系统的单个数据文件中，参数：innodb_file_per_table。

通用表空间

如果我们没有自己去创建，是没有这个通用表空间的，需要通过CREATE TABLESPACE来创建，我们可以为表指定表空间

CREATE TABLE [name] (......
)TABLESPACE [spacename];

这样可以使得多个表共享一个ibd文件，避免ibd文件过多，当然，这些表依旧是独立的，我们可以将许多小型的表集中存储，可以减少磁盘碎片，简化管理，并且利于批量的备份恢复。

撤销表空间

在mysql实例初始化时会自动创建两个默认的undo表空间，初始大小16M，用于存储undo log日志，保证事务的原子性和一致性，主要用于支持事务的回滚操作。

临时表空间

用于存储用户创建的临时表，比如说多表查询时会创建一个临时表，我们在执行查询/排序/GROUP BY等等的复杂操作时，可能会产生一个临时表存储中间结果，而这个临时表就存储在临时表空间当中，查询结束后，就会自动清理。

双写缓冲区

InnoDB引擎将数据页从buffer pool刷新到磁盘前，先会将数据页写入到双写缓冲区文件，便于系统异常时恢复。

重做日志

redo log，用来实现事务的持久性，由重做日志缓冲区和重做日志文件两部分组成，前者位于内存，后者位于磁盘，当事务提交之后，会将所有修改信息都存到该日志中，用于在刷新脏页到磁盘发生错误时的数据恢复使用。

而我们的redo log是一个循环写的机制，这一点和redis的AOF很像。

1.3 后台线程

将内存中缓存池的数据在合适的时机刷新入磁盘中。

Master Thread

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

IO Thread

在innodb引擎中，采取了AIO，也就是异步非阻塞IO，极大地提高了数据库的性能，我们的IO Thread主要负责这些异步请求的回调。

Read Thread：读操作
Write Thread：写操作
Log Thread：将日志缓冲区刷新到磁盘
Insert Buffer Thread：将写缓冲区的数据刷新到磁盘

Purge Thread

回收事务已经提交的Undo Log，事务提交之后，之前记录的undo log不再使用，就用purge thread来回收

Page Cleaner Thread

协助Master Thread刷新脏页到磁盘的线程，减轻核心后台线程的压力。

2. 事务原理

2.1 事务

前文我们知道，事务是密不可分的集合，具有ACID的特性，原子性，一致性，隔离性，持久性。

其中，原子性，一致性和持久性是由我们的redo log和undo log支持实现的；而隔离性是由我们InnoDB的锁机制和MVCC(多版本并发控制)实现的。

2.2 redo log

重做日志，记录事务提交时的数据页的修改，用来实现持久性，由redo log buffer和redo log file两部分组成，前者内存，厚泽磁盘，事务提交之后，会把所有修改信息都存到该日志文件中，用于刷新脏页到磁盘，发生错误时进行数据恢复使用，大致流程如下：

客户端向mysql服务端发起update操作
mysql查询buffer pool，发现没有我们需要更新的数据。
启动后台线程，从后台读取我们需要的信息，随后写入到缓冲区，此时就可以直接对缓冲区进行操作，并且会将增删改的数据写入到redo log buffer当中，此时磁盘和内存数据不一致，称之为脏页。
那么我们如果定期将内存的数据刷新到磁盘，此时出错了，如果没有redo log buffer，我们的事务已经提交，说明了无法得到数据持久性保证，但是我们有了redo log，我们的redo log buffer会直接将修改的数据刷新到磁盘中的redo log file，如果出错了，就会通过redo log file恢复数据，**为啥redo log buffer不直接刷新到真正的数据页？**因为我们真正的数据页刷新将会是随机的IO，而直接记录到日志上是顺序写，所以性能更高。
而我们的redo log日志是类似循环写的模式，每隔一段时间都会被清理。

2.3 undo log

undo log日志解决原子性问题，叫做回滚日志，记录数据被修改前的操作，它可以提供回滚和MVCC(多版本并发控制)，undo log和redo log的记录物理日志不一样，他是逻辑日志，比如说我们insert一条信息，在undo log中就是delete的形式记录，当我们执行rollback，就可以读取到相应的内容进行回滚。

undo log在事务执行时产生，但是在事务提交时并不会立刻删除，因为这些日志还可能用于MVCC，并且undo log采取段的方式时机管理和记录，存在rollback段，内部包含1024个undo log。

3. MVCC(多版本并发控制)

3.1 当前读

读取的是记录最新版本的记录，会加锁保证其他并发事务不会修改，我们在事务隔离级别可重复读中使用事务，如果在进入事务之后，有数据被修改，那么我们读取到的数据并不是最新的，也就不是当前读，如果想要当前读，我们可以执行 SELECT ... LOCK IN SHARE MODE ，初次之外，还可以使用 SELECT FOR UPDATE/INSERT/DELETE 来实现当前读。

3.2 快照读

简单的selete就是我们的快照读，比如我们在可重复读的事务隔离级别中，就是典型的快照读，不加锁，是非阻塞读，当然，在我们的串行化的事务隔离级别中，快照读就会退化为当前读，在read committed中，每次select都会生成一个快照读。

3.3 MVCC

多版本并发控制，它会维护一个数据的多个版本，使得读写操作没有冲突，快照读为mysql实现mvcc提供了一个重要的非阻塞读功能，当，MVCC还依赖于数据库记录的三个隐式字段，undo log， readview。

隐式字段

当我们创建表的时候，会指定相应的表结构，包括id，name，age的字段，我们可以显式的看到这些字段，但是实际上，mysql还未我们隐藏了三个额外增加的字段：

DB_TRX_ID：最近修改事务ID，记录最后插入或修改这一行的事务ID。

DB_ROLL_PTR：回滚指针，指向这条记录的上一个版本，配合undo log。

DB_ROW_ID：隐藏主键，如果表结构没有主键，就会生成这个隐藏字段。

undo log

我们之前提过，undo log在一定情况下不会被立即删除，比如update和delete，产生的undo log不仅在回滚时需要，快照读的时候也需要，所以不会被立即删除，而insert只会在回滚的时候才需要，所以在事务提交的时候可以立即删除，下面来看看实例分析：

借用一下黑马程序员的图

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

以上的示例列举的进行修改操作时的MVCC的版本链的控制，而执行查询操作的时候，则涉及到了另一个组件readView

readview

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

m_ids：当前活跃的事务ID的集合

min_trx_id：最小的活跃事务ID

max_trx_id：预分配事务ID，当前最大事务ID + 1

creator_trx_id：readview创建者的事务ID

版本链访问规则：

trx_id(当前事务ID) == creator_trx_id：ok，说明数据是当前事务更改的。

trx_id < min_trx_id：ok，说明数据已经提交。

trx_id > max_trx_id：no，该事务是在readview生成后才开启的。

min_trx_id <= trx_id <= max_trx_id && trx_id 不存在于m_ids中：ok，数据已经提交。

readview生成时机在不同隔离级别有所不同：

read committed：事务每次执行快照读时，都会生成。(这里建议去看看黑马的视频里面的分析)

repeatable read：在事务第一次执行快照读时生成readview，后续复用这个readview。

ax_trx_id && trx_id 不存在于m_ids中：ok，数据已经提交。

readview生成时机在不同隔离级别有所不同：

read committed：事务每次执行快照读时，都会生成。(这里建议去看看黑马的视频里面的分析)

repeatable read：在事务第一次执行快照读时生成readview，后续复用这个readview。

这样，原理就介绍完毕了。

下午把lab做完了，继续学可能效率不太高，就把之前欠的账补上了。