Day2
-
重做日志缓存：InnoDB除了有缓存池之外，还有重做日志缓存（这样可以异步的将重做日志写入文件）。大小默认8MB
- 重做日志缓存刷入文件时机：（三者取一即可刷入文件）
- Master thread 每秒钟刷一次
- 每个事务提交的时候
- 当重做日志缓存剩余空间小于1/2时
- 重做日志缓存刷入文件时机：（三者取一即可刷入文件）
-
Master thread的工作方式：由多个循环组成
- 主循环：每秒和每十秒会分别执行一次操作（操作太细，以后再看）
- 后台循环：当前没有用户获得或者数据库关闭的时候就会切换到这个循环
- 删除无用的Undo页
- 合并20个插入缓冲
- 跳回到主循环
- 不断刷新100个页知道符合条件
-
关系型数据库的核心：表
-
Unique Not Null作为备选的隐式主键列
-
InnoDB逻辑存储结构
-
表空间->段->区->页->行
-
表空间只存放：数据、索引、插入缓冲bitmap页
-
段：分为数据段、索引段、回滚段
- 数据段其实就是B+树的叶子节点
- 索引段就是B+树的非叶子节点
-
区：连续页组成的空间，每个区大小固定为1MB。默认情况下，InnoDB的页大小为16KB，所以一个区一共有64个连续页
-
页：也叫做块，是InnoDB磁盘管理的最小单位
- 页的类型：数据页，undo页，系统页，事务数据页
-
页结构：
每个页都有两个固定的行记录 infimum and Supremum。分别代表比该页中任何主键值都要小的值和比该页中任何主键值都要大的值。
-
B+树的节点是页地址
-
-
- 约束和索引：
- 当用户创建一个唯一索引的时候，同时也创建了一个唯一的约束
- 但约束是逻辑层次上的概念。而索引更多是物理存储的方式
-
视图：命名虚表，并不是持久表
-
索引：索引太多，影响性能；索引太少，影响查询性能
- 正确的开发模式，要在建表时就添加索引
-
InnoDB索引分类：
- B+树索引
- 全文索引
- 哈希索引
- 哈希索引比较特殊，由引擎自适应生成，不能显式指定
- B+树是传统意义索引，B+树索引的搜索结果是数据行所在的页。然后数据库将该页读入内存（页是硬盘操作的基本单位），再在内存中进行查找。
- B+树的结构（两层为例）：
- 关键词：节点是页、双向链表、多旋转少拆分
- B+树在数据库中扇出很高(fan out)，每一层节点多，所以层数少，一般是2-4层。这样子的话一般最多只做2-4次IO
- 聚集索引（clustered index）：按每张表的主键构造一颗B+树，同时叶子节点中存放的即为整张表的行记录数据。所以多数情况下，查询优化器倾向于采用聚集索引，这样可以直接在B+树索引的叶子节点上找到数据。
- 辅助索引（Secondary index）：叶子不包含行记录的全部数据，叶子节点除了包含键值以外，每个叶子节点的索引行中还包含了一个书签，用来告诉InnoDB存储引擎，哪里可以找到与索引对应的行数据
- 辅助索引的存在并不影响数据在聚集索引中的组织，因此每张表上可以有多个辅助索引。当通过辅助索引来查找数据时，我们最终会找到位于叶子上的只想主键索引的主键指针，然后通过主键索引来找到一个完整的行记录。
- eg：高度为3的辅助索引树和高度为3的聚集索引树(主键索引树)，最终进行6次逻辑磁盘IO
- 索引适用的情景：列属性具有高选择性，即值得范围很多样（这样才能保证B+树的有效性）
- cardinality表示表中某一列的选择性（越接近1，选择性越高）；数据库通过采样来确定cardinality
- 联合索引：每个节点多个键值的B+树
- 全文检索：B+树索引用索引字段或者索引字段的前缀进行搜索。而形如%XXX%的索引字段，B+树就效率很低了，这时我们采用全文索引
- 全文索引一般使用倒排索引实现（inverted index），用辅助表记录文件ID与文件Text中存在单词的映射关系。
- Innodb采用的是full inverted index的存储方式。这种方式会占用更多的空间，因为它不仅会存储单词和单词所在文档的ID，还会存储单词所在文档的ID中具体的位置。可以用一个简单的表格来解释
