版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/crowhyc/article/details/81906258
1.缓冲池：
- 所有对数据库的操作首先修改缓冲池中的页，在合适的 checkpoint 再写入磁盘存储中。
- 缓冲池的大小决定着数据库的性能。
- 缓冲池通过 LRU 的算法进行管理。即使用最多的页在前端，最少使用的在尾端。当缓冲池不能存新的页的时候，将首先清理尾端的页。页大小默认为16KB,
- innodb 优化了 LRU 算法，在 LRU 的列表中加入了 midpoint 的位置。每次最新访问的页放入到 midpoint 的位置，默认为5/8的地方。默认 LRU 算法是直接插入头部，但是为了增加热度较高页面的存活时间，所以在中部插入。避免了大量 SQL 查询导致的高热度页被刷出
2.两次写：
为了避免在宕机时，正好数据库在写入某页面列表中，导致了页面被污染，但是又使用重做日志又没有干净的页面可以直接重写。所以 mysql 对脏页进行更新的时候，使用了两次写的方案来解决。
- 两次写拥有额外的两个不同的存储地址。一个是内存的 doublewirte buffer 一个是物理磁盘上的共享空间，都是2MB 正好是128页。
- 在对缓冲池的脏页刷新时，先将脏页复制到 buffer 中。然后在分两次把 buffer 的内容顺序的写入到内存共享空间。然后再从 buffer 同步磁盘。整个过程都是顺序的。如果一旦出现异常，可以通过恢复共享空间的数据到表空间文件，再使用重做日志的方式来实现恢复。
3.索引：
innoDB 有3中索引：B+树索引、hash 索引、全文索引
B+索引具有高扇出性，树的高度一般在2-4层
3.1自适应 hash 索引:
- hash 索引是系统自行选择建立的，不能人工建立
- 通过缓存池的 B+树结构来建立的
3.2B+树索引：
3.2.1使用目的(为什么使用 b+tree)：
- b+树在同样的数据量下可以有效的减少树的层级，有效的减少查询时候的 I/O次数
- 对比红黑树，b+树的节点是按范围进行存储，有效的提高的了查询效率
- 对比平衡二叉树，b+树不需要使用大量的处理去维护最优，同时又能保证查询的高效
3.2.1聚合索引：
- 通过主键建立的索引
- 叶子节点里面的数据就是对应的行数据
- 由于叶子节点间使用双向链方式。所以范围查找非常便利
3.2.2辅助索引：
- 通过设定值进行建立索引
- 叶子节点上通过 bookmark 保存对应引用，本引用是对应主键。所以查询流程是先走辅助索引的树，然后去走聚合索引的树。IO 次数是2颗树高度相加
3.2.3联合索引：
按建立联合索引的键的顺序全排列出所有的 key 组合。例如index(a,b) -> (1,1) (1,2)(2,1)(2,2)。如果使用 where A=XXX and B=XXX & where a=XXX 都可以使用到这个联合索引。但是where b=xxx 是不能使用到的。联合索引的组合方式实际上对a b c。。。等联合键值都进行了排序。所以where a=xxx order by b是可以使用到索引的
3.3全文索引：
待补充