《Mysql技术内幕，Innodb存储引擎》—

B+树

B+树中，所有记录节点都按照键值的大小顺序放在同一层叶子节点，各个叶子节点指针进行连接。

图中指针是单向的，但是书上的图是双向的，而且旋转应该也是双向才能完成）

B+树插入处理

Leaf Page满	Index Page 满	操作
No	No	直接插入到叶子节点
Yes	No	1. 拆分Leaf Page 2.将中间的节点值加入到Index Page中 3. 中间节点左边的记录放拆分后的左页 4. 其余（包括中间节点）放右页
Yes	Yes	1. 拆分Leaf Page，步骤与上条一致（当作IndexPage还未满） 2. 拆分Index Page，将其与普通Leaf Page看待

页拆分意味着层次增加，因此B+树也会进行旋转。当Leaf Page满了的时候，会去查看其左右兄弟页是否已满，若未满则会移动记录到兄弟页上，通常顺序是先左后右。

B+树删除操作

删除合并叶子的标准是填充因子(fill factor)，50%是可以设置的最小值。

Leaf Page小于填充因子	Index Page 小于填充因子	操作
No	No	直接在叶子节点中删除该记录，若该记录是Index Page中的值则将该记录的右边记录代替
Yes	No	合并叶子节点和它的兄弟节点，更新Index Page
Yes	Yes	1. 合并叶子节点和其兄弟节点 2. 更新Index Page 3. 合并Index Page和其兄弟节点

B+树索引

聚集索引

Innodb中每张表都会有一个聚集索引，其行记录存在该索引的叶子节点上。
叶子节点通过双向链表链接，按照主键的顺序排序
页中的记录也是双向链表进行维护，物理上可以不按照顺序存储。
所有索引只能定位到页，不能通过索引定位到具体的行，到页后通过Page Directory确定行。

辅助索引

叶子节点不包含行记录，只有创建索引定义的值和一个指针（叫书签）指向其对应的聚集索引叶节点。

B+树索引分裂

因为索引的顺序很多情况下是递增的，如果此时还从中间分裂的话会导致很大的浪费，因此对其进行部分改进。

如果插入是随机的，取页的中间记录作为分裂点记录。
若同一方向进行插入的记录数为5，且如果插入新记录的位置后，如果还有3条记录则分裂点在其后第3条记录，如果没有3条那么分裂点就是新插入的这条记录（新记录分到新页）

B+树索引管理

1. 索引管理

show index from tablename可查看索引信息，其中Cardinality表示索引中唯一值的估计值（最好能接近1，如果非常小则可以考虑删除该索引），优化器根据该值判断是否选择使用该索引。
cardinality值是通过简单抽样统计出来的，默认随机取8个叶子节点数据统计其平均值(不足8页则全取)。
cardinality更新策略：表中1/16的数据已经发生变化或stat_modified_counter>2000000000（每个表维护一个stat_modified_counter，每次DML更新1行就加1，直到满足阈值则自动收集统计信息，并把此值清0；）

2. Fast Index Creation

Mysql5.5之前添加或删除索引的操作过程：

1. 创建新临时表，再通过Alter table定义新结构

2. 将原表数据导入临时表

3. 删除原表，将临时表重命名

进行操作时不可访问。

Fast Index Creation(FIC)会对创建索引的表加S锁，不需要建新表。删除索引则只更新数据库内部视图删除对该索引的定义即可。
FIC可以使修改索引时提供查询操作，然而事物操作还是不能提供。

3. Online Schema Change

在线架构改变(OSC)，在修改索引是可以同时进行事物处理。步骤如下：

1.检查必要条件，如表是否有主键等。

2.创建与原始表相同表，并修改其索引或列。

3.创建deltas表，对原表创建insert、update和delete触发器，将产生的记录写入deltas表

4.开始OSC操作事物

5.将原表数据写入新表

6.将deltas表记录事物回放

7.交换表名，需要锁两张表。

书上的步骤写的有点不懂，为什么导数据前要先删除新表索引？所以只简略写下大致步骤

4. Online DDL

Mysql5.6开始支持，允许辅助索引创建与删除、改变自增长值、添加删除外键约束和列重命名时进行DML操作。

alter table table_name

| add {index|key} [index_name]

[index_type] (index_col_name,...) [index_option]..

algorithm [=] {default|inplace|copy}

lock [=] {default|none|shared|exclusive}

algorithm指定修改索引的算法，copy表示创建临时表方法，inplace表示不需要临时表，default则根据配置文件选。
lock为修改索引时对表加锁情况，none不加任何锁，share加S锁，exclusive加X锁，default则按照前面的顺序判断是否可用。
原理是在执行过程中将DML操作日志写入缓存中，等索引创建后再重新应用到表上。

B+树索引的使用

联合索引，索引的有序性可用于排序，减少内存排序。
覆盖索引，当要查询的值都在一个二级索引时，此时不需要去聚集索引查询记录值可直接返回结果。
from table_name force index(filed_name) where ...，可强制使用索引。
using index 是告诉优化器可以选择该索引

Multi-Range Read 优化

减少随机IO，将随机IO转化为顺序IO。主要有利于范围查询

工作方式：

1. 将查询的辅助索引值放入缓存

2. 对缓存中键值RowId进行排序

3. 根据RowId顺序load 页

还可以将某些范围查询拆分为键值对，以此批量查询数据。

Index Condition Pushdown优化

ICP在使用索引时会对where条件进行过滤（以前是不过滤直接查出所有记录再筛选）再去获取记录，前提是条件字段必须能在该索引覆盖范围内。

全文索引

Innodb1.2开始支持全文索引，原理还是倒排索引。

倒排索引

倒排索引在辅助表(auxiliary table)中存储词与文档的映射关系（主键是词）。
inverted file index，{词，docIdList}
full inverted index，{词，(docId:position)...}，innodb使用此形式。

Innodb全文检索

将(docId,position)看作一个ilist，其全文检索表中有两列，word和ilist，word列建有索引。
其共有6张辅助表，每张表根据word的Latin编码进行分区。
辅助表是持久表，存放在磁盘。
FTS Index Cache(全文检索索引缓存)是一个红黑树，根据(word,ilist)排序。
插入数据分词后，数据不直接写入辅助表，而是写入FTS Index Cache，其查询将会把Cache与辅助表合并。
事物提交时写入FTS Index Cache，然后再通过批量更新写入磁盘。
当宕机使FTS Index Cache数据丢失，则下次当使用全文检索时Innodb将自动读取未完成的文档，然后进行分此操作，再将分词结果写入FTS Index Cache。
使用全文索引的表必须有一个字段与word进行映射，命名为FTS_DOC_ID类型必须为BIGINT UNSIGNED NOT NULL，若没有则将自动创建并加上unique index。
删除记录时不删除辅助表的记录，只删除FTS Index Cache中记录，并将docId保存在DELETE辅助表
全文检索限制：每张表只能用一个全文检索索引、多列组合的必须使用相同字符集与排序规则、不支持中文。。。