Mysql框架分析和Innodb分析

Mysql的大体架构图：

主要构成：
1. 连接池组件
2. 管理服务
3. 工具
4. sql接口
5. 查询分析器
6. 优化器
7. 缓冲
8. 插入式储存引擎
9. 物理存储文件

Innodb分析

工作方式：将数据文件按页（每页16K）读入InnoDB buffer pool，然后按最近最少使用算法（LRU）保留缓存数据（缓存的数据页类型包括 索引页 数据页 undo页 insert buffer 自适应哈希索引 InnoDB锁信息以及数据字典信息等），通过一定频率刷新到文件。
后台线程默认7个:4个IO Thread，1个master Thread，1个锁监控线程，1个错误线程

master Thread：由四个循环组成：
1. 主循环
2. 后台循环
3. 刷新循环
4. 挂起循环

Innodb最关键的三个特性：

1. 插入缓存
2. 二次写
3. 自适应Hash索引

插入缓存
需要插入缓存的原因：
主键索引为聚集索引，辅助索引（非聚集索引）是依赖于聚集索引，如果对非聚集索引关键字进行更新修改，索引需要多次操作。
解决方法：
为了解决这个问题，InnoDB设计出了插入缓冲技术，对于非聚集类索引的插入和更新操作，不是每一次都直接插入到索引页中，而是先插入到内存中。具体做法是：如果该索引页在缓冲池中，直接插入；否则，先将其放入插入缓冲区中，再以一定的频率和索引页合并，这时，就可以将同一个索引页中的多个插入合并到一个IO操作中，大大提高写性能。这个设计思路和HBase中的LSM树有相似之处，都是通过先在内存中修改，到达一定量后，再和磁盘中的数据合并，目的都是为了提高写性能。

启用需要满足一下两个条件：
1）索引是辅助索引（secondary index）
2）索引不适合唯一的
如果辅助索引是唯一的，就不能使用该技术，原因很简单，因为如果这样做，整个索引数据被切分为2部分，无法保证唯一性。

缺点：
任何一项技术在带来好处的同时，必然也带来坏处。插入缓冲主要带来如下两个坏处：
1）可能导致数据库宕机后实例恢复时间变长。如果应用程序执行大量的插入和更新操作，且涉及非唯一的聚集索引，一旦出现宕机，这时就有大量内存中的插入缓冲区数据没有合并至索引页中，导致实例恢复时间会很长。
2）在写密集的情况下，插入缓冲会占用过多的缓冲池内存，默认情况下最大可以占用1/2，这在实际应用中会带来一定的问题。

二次写：
想象这么一个场景，当数据库正在从内存向磁盘写一个数据页时，数据库宕机，从而导致这个页只写了部分数据，这就是部分写失效，它会导致数据丢失。这时是无法通过重做日志恢复的，因为重做日志记录的是对页的物理修改，如果页本身已经损坏，重做日志也无能为力。

需要额外添加两个部分：
1）内存中的两次写缓冲（doublewrite buffer），大小为2MB
2）磁盘上共享表空间中连续的128页，大小也为2MB

其原理是这样的：
1）当刷新缓冲池脏页时，并不直接写到数据文件中，而是先拷贝至内存中的两次写缓冲区。
2）接着从两次写缓冲区分两次写入磁盘共享表空间（磁盘）中，每次写入1MB
3）待第2步完成后，再将两次写缓冲区写入数据文件

这样就可以解决上文提到的部分写失效的问题，因为在磁盘共享表空间中已有数据页副本拷贝，如果数据库在页写入数据文件的过程中宕机，在实例恢复时，可以从共享表空间中找到该页副本，将其拷贝覆盖原有的数据页，再应用重做日志即可。

自适应Hash索引：
InnoDB存储引擎会监控对表上索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以称之为自适应（adaptive） 的。自适应哈希索引通过缓冲池的B+树构造而来，因此建立的速度很快。而且不需要将整个表都建哈希索引，InnoDB存储引擎会自动根据访问的频率和模式 来为某些页建立哈希索引。