mysql Innodb引擎，笔记

1.版本

2.体系架构

简单解释：由文件，内存，线程组成
文件：数据文件
InnoDB内存池：内存
后台线程：数据文件与内存交互（数据同步，日志记录等）

为了提高效率，需要将数据文件加载进内存，crud操作实际上是在内存中操作（同时后台线程会有日志记录），之后由后台线程同步文件，所以内存的大小直接影响着数据库的效率

2.1 InnodB内存池（一块内存）

数据页的概念：一页16kb，也就是说页是一个单位

查询
首次查询时，会检查内存中是否存在这些数据页，如果没有就去文件中取并放入内存，第二次查询时，检查内存中有这些数据页，就不必再去文件中取
页修改
先修改缓存池中的页，之后再刷新到文件中（刷新操作是由一个机制触发）

2.1.1.缓冲池

缓冲池可以有多个
内存池中的数据页类型：

LRU算法(Latest Recent Used最近最少使用)

由于内存资源十分宝贵，不常用的数据被称为冷数据，需要从内存中剔除
InnoDB还对其进行了优化，就是读取到的页不会放在LUR列表的首部，而是放在5/8的位置（midpoint），midpoint之前的被称为new列表，之后的称为old列表，mid位置需要等待一段时间之后才会放入new列表（卧槽！有点像是jvm的内存回收机制），为什么不直接放入LRU的首部？万一某次的操作只使用了一次，且占用了整个new列表，就会影响效率

21.2 LRU列表，Flush列表，Free列表

2.1.3 重做日志

事务提交时，产生重做日志，先写重做日志之后再去修改页，这样的话，即使刷新到硬盘时宕机，也能够根据重做日志恢复数据

2.2 checkPoint

3 innoDB 关键特性

3.1插入缓冲

简单理解为，插入（更新，删除）成功了，但是在内存中的一颗B+树中，（这课树不属于某张表，唯一且共享）且不在对应的内存页中，在查询或者其他策略触发时，才真正的去插入（更新，删除）到表，（类似git的合并）（前提条件：非唯一的辅助索引）

3.2 两次写（没看懂）

问题1:如何判断页是否损坏
问题2:页副本是从共享表空间中取得的，然而页损坏本来就是write到磁盘>是宕机，也就是说共享表空间的数据并不完整，怎么能够在共享表空间中>取呢？

架构

可以看到
从缓存写到磁盘时，写了两份，
1.一份是直接放入表
2.一份是放在一个共享的表空间
12步骤是同时进行的，如果12进行时宕机，则数据部分丢失，开机时？后面是咋操作的？没看懂

数据丢失的情况

InnoDB重做日志记录的是对页对物理操作
部分写失效的情况的页被称为损坏的页

自适应哈希索引

异步IO

类似多线程执行大任务，分解大任务为小任务，最后合并任务结果

刷新邻接页