InnoDB存储引擎-索引与算法（4）

1.索引的结构

插入操作：

并不是总是在中间分裂的，这个得看配置的参数。

删除操作：

聚集索引

InnoDB存储引擎表是索引组织表，即表中数据按照主键顺序存放。

聚集索引的存储并不是物理上连续的，而是逻辑上连续的。这其中有两点：一是前面说过的页通过双向链表链接，页按照主键的顺序排序；另一点是每个页中的记录也是通过双向链表进行维护的，物理存储上可以同样不按照主键存储。

辅助索引

也称非聚集索引， 叶子节点并不包含行记录的全部数据。叶子节点除了包含键值以外，每个叶子节点中的索引行中还包含了一个书签（bookmark）。

联合索引

联合索引是指对表上的多个列进行索引，联合索引上面的键都是有序的

覆盖索引

从辅助索引中就可以得到查询的记录，而不需要查询聚集索引中的记录

2.Cardinality值

Cardinality值非常关键，表示索引中不重复记录数量的预估值，简单来说就是随机采样，然后统计计算。Cardinality/n_rows_in_table应尽可能地接近1

Cardinality统计信息的更新时机： INSERT和UPDATE的操作，

❑表中1/16的数据已发生过变化。

❑stat_modified_counter＞2 000 000 000。

同样是通过采样的方法。默认InnoDB存储引擎对8个叶子节点（Leaf　Page）进行采用。采样的过程如下：

❑取得B+树索引中叶子节点的数量，记为A。

❑随机取得B+树索引中的8个叶子节点。统计每个页不同记录的个数，即为P1，P2，…，P8。

❑根据采样信息给出Cardinality的预估值：Cardinality=（P1+P2+…+P8）*A/8。

3.优化器选择使用不同索引

如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。因为之前已经提到过，顺序读要远远快于离散读。

FORCE INDEX：强制执行索引

USE INDEX：加入索引考虑范围

4.Multi-Range Read优化

Multi-Range Read优化的目的就是为了减少磁盘的随机访问，并且将随机访问转化为较为顺序的数据访问，这对于IO-bound类型的SQL查询语句可带来性能极大的提升。Multi-Range Read优化可适用于range，ref，eq_ref类型的查询。

MRR优化有以下几个好处：

❑MRR使数据访问变得较为顺序。在查询辅助索引时，首先根据得到的查询结果，按照主键进行排序，并按照主键排序的顺序进行书签查找。

❑减少缓冲池中页被替换的次数。

❑批量处理对键值的查询操作。

对于InnoDB和MyISAM存储引擎的范围查询和JOIN查询操作，MRR的工作方式如下：

❑将查询得到的辅助索引键值存放于一个缓存中，这时缓存中的数据是根据辅助索引键值排序的。

❑将缓存中的键值根据RowID进行排序。

❑根据RowID的排序顺序来访问实际的数据文件。

5.Index Condition Pushdown（ICP）优化

当进行索引查询时，首先根据索引来查找记录，然后再根据WHERE条件来过滤记录，从而减少返回给mysql应用层的数据量。

当优化器选择Index Condition Pushdown优化时，可在执行计划的列Extra看到Using index condition提示。

可见Index Condition Pushdown优化可以将查询效率在原有MySQL 5.5版本的技术上提高23%。而再同时启用Mulit-Range Read优化后，性能还能有400%的提升！

6.哈希算法

未看。。。。。。。。。。

7.全文索引