Innodb+杂记

一、内存
LRU算法（last recent used）：最频繁使用的页在列表前端，最少使用的页在LRU列表的微端。当缓冲池不能存取新都区到的也是，将首先释放LRU列表的尾段页。
优化：加入midpoint位置最新读取到的，虽然是最新访问的页，但并不是放到列表的首部。而是放到midpoint位置。

大概在尾端的37%位置。之前的叫new列表，之后的叫old列表。new里边中的页都是最为活跃的热点数据。

innodb_old_blocks_time：也读取到min位置后需要等待多久才能加到LRU列表的热端。

如果是全表扫描，呆不了这么久。所以就不会把热点的数据页清出去

重做日志缓冲：首先将重做日志信息放到这个缓冲区中，然后按照一定频率将其刷新到重做日志文件。

额外内存池：有些内存可以在这里申请。

Checkpoint技术：（检查点）checkpoint之前的数据都已经全部刷到磁盘中。在检查点之后，系统蹦极前提交的都须重做，系统蹦极时还没提交的都回滚
可以缩短数据恢复的时间。同时防止缓冲池不够用

Innodb关键特性
插入缓冲：插入缓冲,并不是缓存的一部分,而是物理页,对于非聚集索引的插入或更新操作,不是每一次直接插入索引页.而是先判断插入的非聚集索引页是否在缓冲池中.如果在,则直接插入,如果不再,则先放入一个插入缓冲区中.然后再以一定的频率执行插入缓冲和非聚集索引页子节点的合并操作.
使用条件:
非聚集索引（即属于辅助索引）：聚集索引基本都是有序的，也不需要插入缓冲，可以直接插入
非唯一：要求数据唯一的话，插入之前都需要做一次是否唯一的判断，即需要进入索引页中判断。这时候再插入“缓冲”就没有意义了

总结：Insert Buffer 就是用于提升非聚集索引页的插入性能的，其数据结构类似于数据页的一个B+树。

两次写：nnoDB的Page Size一般是16KB，其数据校验也是针对这16KB来计算的，将数据写入到磁盘是以Page为单位进行操作的。我们知道，由于文件系统对一次大数据页（例如InnoDB的16KB）大多数情况下不是原子操作，这意味着如果服务器宕机了，可能只做了部分写入。16K的数据，写入4K时，发生了系统断电/os crash ，只有一部分写是成功的，这种情况下就是partial page write问题。
有经验的DBA可能会想到，如果发生写失效，MySQL可以根据redo log进行恢复。这是一个办法，但是必须清楚地认识到，redo log中记录的是对页的物理修改，如偏移量800，写’aaaa’记录。如果这个页本身已经发生了损坏，再对其进行重做是没有意义的。
为了解决这个问题，InnoDB实现了double write buffer，简单来说，就是在写数据页之前，先把这个数据页写到一块独立的物理文件位置（ibdata），然后再写到数据页。这样在宕机重启时，如果出现数据页损坏，那么在应用redo log之前，需要通过该页的副本来还原该页，然后再进行redo log重做，这就是double write。double write技术带给innodb存储引擎的是数据页的可靠性，下面对doublewrite技术进行解析，让大家充分理解double write是如何做到保障数据页的可靠性。
double write由两部分组成，一部分是InnoDB内存中的double write buffer，大小为2M，另一部分是物理磁盘上ibdata系统表空间中大小为2MB，共128个连续的Page，既2个分区。其中120个用于批量写脏，另外8个用于Single Page Flush。做区分的原因是批量刷脏是后台线程做的，不影响前台线程。而Single page flush是用户线程发起的，需要尽快的刷脏并替换出一个空闲页出来。
double write工作流程如下：
当一系列机制（main函数触发、checkpoint等）触发数据缓冲池中的脏页进行刷新到data file的时候，并不直接写磁盘，而是会通过memcpy函数将脏页先复制到内存中的double write buffer，之后通过double write buffer再分两次、每次1MB顺序写入共享表空间的物理磁盘上。然后马上调用fsync函数，同步脏页进磁盘上。由于在这个过程中，double write页的存储时连续的，因此写入磁盘为顺序写，性能很高；完成double write后，再将脏页写入实际的各个表空间文件，这时写入就是离散的了。各模块协作情况如下图（第一步应为脏页产生的redo记录log buffer，然后log buffer写入redo log file，为简化次要步骤直接连线表示）

自适应哈希索引：B+取决于高度，哈希一般O（1）。
Innodb会监控对标上个索引页的查询，如果观察到建立哈希索引可以带来速度提升，则建立哈希索引，称为自适应哈希索引。不需要对整张表建立，自动根据访问的频率和模式来为某些热点页建立哈希索引。

异步IO：为了提高磁盘操作性能，当前的数据库系统都采用异步IO（Asynchronous IO，AIO）的方式来处理磁盘操作。InnoDB存储引擎就是这样。
与AIO对应的Sync IO，即每进行一次IO操作，需要等待此操作结束才能继续接下来的操作。但是如果用户发出的是一条索引扫描的查询，那么这条SQL查询语句可能需要扫描多个索引页，也就是需要进行多次的IO操作。在每扫描一个页并等待其完成后再进行下一次的扫描，这是没有必要的。用户可以在发出一个IO请求后立即再发出另一个IO请求，当全部IO请求发送完毕后，等待所有IO操作的完成，这就是AIO。
总结：同时扫描多个索引页

刷新临近页：当刷新一个脏页时，innodb存储引擎会检测该页所在区(extent)的所有页，如果是脏页，那么一起进行刷新。这样做的好处显而易见，通过AIO可以将多个IO写入操作合并为一个IO操作，增大写入量，减少了物理写IO，故该工作机制在传统机械磁盘下有着显著的优势。
　　1）、在写入次数基本不增加的情况下，增加了写入的量；
　　2）、加速了脏页的回收；
　　3）、充分利用double write每次1M写入的特征；
　　4）、这个功能打开以后会发现iostat里面的wrqm(合并写)这个值会比较高；

二、索引
B、B+、B-
B树 即二叉搜索树：
B-：是一种多路搜索树（并不是二叉的）。任何一个关键字出现且只出现在一个结点中，搜索有可能在非叶子结点结束。（所以不支持顺序查找）
B+：所有关键字都在叶子结点出现，为所有叶子结点增加一个链指针（所以支持顺序查找）

全文索引：
使用倒排索引。在辅助表中存储了单词与单词自身在一个或多个文档中所在位置。
倒排索引它需要将分词（word）存储在一个辅助表（Auxiliary Table）中，为了提高全文检索的并行性能，共有6张辅助表。辅助表中存储了单词和单词在各行记录中位置的映射关系。它分为两种：倒排文件索引，详细倒排索引
1、inverted file index（倒排文件索引），表现为{单词，单词所在文档ID}
2、full inverted index（详细倒排索引），表现为{单词，(单词所在文档ID, 文档中的位置)}