Log[数据库_InnoDB存储引擎]_20.06.18_log用数据库存储-CSDN博客

本文链接：https://blog.csdn.net/qq_41097894/article/details/106842530

Part 2

InnoDB引擎是第一个完整支持ACID事务的MySQL存储引擎，在正式介绍之前先用几个关键词来概括此引擎的特点就是：行锁、支持MVCC、支持外键、提供一致性的非锁定读。

1.InnoDB体系架构

导图：

InnoDB架构

从上面这张图可以看出InnoDB存储引擎的基本组成结构，完成工作的主要是多个后台线程和内存池。接下来一一介绍一下各部分的工作。

1.1 内存

1.1.1 缓冲池

InnoDB引擎是基于磁盘进行存储的，其中的记录按照页的方式进行管理。*（页的类型多种多样：索引页、数据页、undo页、插入缓冲等大小均为16KB）*磁盘I/O速度慢，为了存储引擎的性能着想，使用缓冲池技术来提高性能。

引入缓冲池技术后，读取数据的流程就变成了这样：数据库请求读取某页——>判断缓冲池有没有此页——>没有则从磁盘读数据——>放到缓冲池——>完成。这样在下次读取时还是按照上述流程判断，在第二步如果答案为肯定，就可以直接从缓冲池中读取此页。

要注意的是，有了缓冲池之后，对数据库页的修改也是先修改缓冲池中的页，再根据一定的频率将修改后的页刷回磁盘。

1.1.2 三种List管理缓冲池

那么如何对缓冲池进行管理呢？缓冲池的管理主要涉及两个问题：池中页的换入换出规则和对池中已被修改但还未刷新回磁盘的页（称为脏页）的管理。

对于问题一，数据库缓冲池中页的置换使用的是LRU机制，支撑此种机制的是一个LRU List，表满换出时，将换出链表最末端的结点。值得注意的是InnoDB对此机制做了优化：引入了midpoint来指示一个位置（该位置通常在链表的5/8处）。规则是将新读取的页不放在链表首部。而是放到midpoint这个位置。这样做主要是为了应对一种场景：进行索引或数据的扫描。在进行这类操作时，往往需要访问表中许多的页，LRU链会被大型置换一次，也就意味着之前因为经常使用而常驻缓冲池的“热点页“，将被刷出缓冲池，而在下一次操作时，由于要使用到它们，又要将其从磁盘读出来。而如果使用了midpoint,热点数据在前面，不会被轻易刷出。

对于问题二，由于脏页的刷新是在一段时间后统一刷新的，所以需要进行脏页的统一管理，由Flush List来完成。注意脏页即存在于LRU LIst，也存在于Flush List。

1.1.3 重做日志缓冲

除了缓冲池之外，内存中还有重做日志缓冲，重做日志信息会先放到这个缓冲区，再按一定的频率刷新到重做日志文件。

1.2 后台线程

InnoDB存储引擎是多线程的模型因此后台有多个不同的后台线程，负责处理不同的任务。

Master Thread：负责将缓冲池中数据异步刷新到磁盘，保证一致性。包括脏页刷新、合并插入缓冲、UNDO页回收等。

IOThread：InnoDB中使用了大量AIO来处理IO请求，I/O Thread按照类型分为四种：write、read、insert buffer、log 。分别处理不同的情况。

Pruge Thread：事务被提交后，记录其历史版本的undolog页可能不再需要，Pruge Thread线程就负责回收undolog页

Page Cleaner Thread：1.2.x引入，将脏页的刷新独立到了这个线程中完成

1.3 InnoDB关键特性

1.3.1 插入缓冲

在插入时如果要插入聚集索引，一般都是按顺序插入，在一定的插入次数内都不需要去读取磁盘中的其他页，而插入非聚集索引时，由于插入顺序是按主键排的，非聚集索引插入就是无顺序的。可能每一次插入都得从磁盘中读取索引页再进行插入，这样做的效率非常慢。所以InnoDB引入了插入缓冲。插入缓冲本质上是物理页面，存储着需要插入的非聚集索引，在一段时间后，统一刷新到磁盘中对应的索引页中。因为在插入缓冲页中肯定会有一些需要插入在同一个索引页中，大大减少了读取页的次数，由此，效率得到了提高。

1.3.2 两次写

设想一个情况：InnoDB正在将某个页写入表中，在写的过程中数据库发生了宕机，没写进表的数据因为在内存中所以丢失了，这种情况被称为部分写失效。即使有重做日志，重做日志的记录也只是一条条物理操作，如:插入了"xxxx"。但是在这里受到损毁的是表本身，光靠重做日志是不能够完成重建的。所以，在用重做日志前，需要一个页的副本，当写入失效发生时，先通过副本还原该页，再进行重做。
在这里插入图片描述
这样的话，如果在2处宕机，还未往磁盘写，所以磁盘内页面没有被破坏，安全。