MySQL中的索引

索引概述

索引（index）是帮助MySQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。

左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找快速获取到相应数据。
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储在磁盘上。索引是数据库中用来提高性能的最常用的工具。

索引优势劣势

优势

• 类似于书籍的目录索引，提高数据检索的效率，降低数据库的IO成本。
• 通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗

劣势

• 实际上索引也是一张表，该表中保存了主键与索引字段，并指向实体类的记录，所以索引列也是要占用空间的。
• 虽然索引大大提高了查询效率，同时却也降低更新表的速度，如对表进行INSERT、UPDATE、DELETE。因为更新表时，MySQL 不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。

索引结构

MyISAM、InnoDB、Memory三种存储引擎对各种索引类型的支持

索引	InnoDB引擎	MyISAM引擎	Memory引擎
BTREE索引	支持	支持	支持
HASH 索引	不支持	不支持	支持
R-tree 索引	不支持	支持	不支持
Full-text	5.6版本之后支持	支持	不支持

我们平常所说的索引，如果没有特别指明，都是指B+树（多路搜索树，并不一定是二叉的）结构组织的索引。其中聚集索引、复合索引、前缀索引、唯一索引默认都是使用 B+tree 索引，统称为 索引。

BTREE 结构

BTree又叫多路平衡搜索树，一颗m叉的BTree特性如下：

• 树中每个节点最多包含m个孩子。
• 除根节点与叶子节点外，每个节点至少有[ceil(m/2)]个孩子。
• 若根节点不是叶子节点，则至少有两个孩子。
• 所有的叶子节点都在同一层。
• 每个非叶子节点由n个key与n+1个指针组成，其中[ceil(m/2)-1] <= n <= m-1

以5叉BTree为例，key的数量：公式推导[ceil(m/2)-1] <= n <= m-1。所以 2 <= n <=4 。当n>4时，中间节点分裂到父节点，两边节点分裂。

插入 C N G A H E K Q M F W L T Z D P R X Y S 数据为例。
演变过程如下：
1). 插入前4个字母 C N G A

2). 插入H，n>4，中间元素G字母向上分裂到新的节点

3). 插入E，K，Q不需要分裂

4). 插入M，中间元素M字母向上分裂到父节点G

5). 插入F，W，L，T不需要分裂

6). 插入Z，中间元素T向上分裂到父节点中

7). 插入D，中间元素D向上分裂到父节点中。然后插入P，R，X，Y不需要分裂

8). 最后插入S，NPQR节点n>5，中间节点Q向上分裂，但分裂后父节点DGMT的n>5，中间节点M向上分裂
在这里插入图片描述

到此，该BTREE树就已经构建完成了， BTREE树 和 二叉树 相比， 查询数据的效率更高， 因为对于相同的数据量来说，BTREE的层级结构比二叉树小，因此搜索速度快。

B+TREE 结构

B+Tree为BTree的变种，B+Tree与BTree的区别为：

• 叉B+Tree最多含有n个key，而BTree最多含有n-1个key。
• B+Tree的叶子节点保存所有的key信息，依key大小顺序排列。
• 所有的非叶子节点都可以看作是key的索引部分。
  
  由于B+Tree只有叶子节点保存key信息，查询任何key都要从root走到叶子。所以B+Tree的查询效率更加稳定。

MySql索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能。

hash索引

哈希索引（hash index）基于哈希表实现，只有精确匹配索引所有列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码（hash code），哈希码是一个较小的值，并且不同键值的行计算出来的哈希码也不一样。哈希索引将所有的哈希码存储在索引中，同时在哈希表中保存指向每个数据行的指针。

对于hash相同的，采用链表的方式解决冲突。类似于hashmap。因为索引的结构是十分紧凑的，所以hash索引的查询很快。

缺点：
➢ 仅仅能满足“=", "IN”, 不能使用范围查询
➢ 无法被用来避免数据的排序操作
➢ 不能利用部分索引|键查询
➢ 不能避免表扫描
➢ 遇见大量hash值相等的情况后性能不一定比B-tree索引高

密集索引和稀疏索引

密集索引|和稀疏索弓|的区别
➢密集索引文件中的每个搜索码值都对应一个索引值
➢稀疏索引文件只为索引|码的某些值建立索引项

聚簇索引：表数据按顺序存储，即索引顺序和表记录物理存储顺序一致。聚簇索引的叶子节点存储数据行和B-Tree索引。在一个表中只能有一个聚簇索引，因为真实物理存储顺序只能有一种。 可查看：https://blog.csdn.net/riemann_/article/details/90324846

密集索引：叶子节点保存的不只是键值，还保存了位于同一行记录里的其他列的信息，由于密集索引决定了表的物理排列顺序，
		一个表只有一个物理排列顺序，所以一个表只能创建一个密集索引
		
稀疏索引：叶子节点仅保存了键位信息以及该行数据的地址，有的稀疏索引只保存了键位信息机器主键


mysam存储引擎：不管是主键索引，唯一键索引还是普通索引都是稀疏索引

innodb存储引擎：有且只有一个密集索引。
	主键索引(聚簇索引): 叶子节点存的是整行数据 是 密集索引
	非主键索引(二级索引): 叶子节点内容是主键的值, 是稀疏索引
	密集索引的选取规则如下：
		若主键被定义，则主键作为密集索引
		如果没有主键被定义，该表的第一个唯一非空索引则作为密集索引
		若不满足以上条件，innodb内部会生成一个隐藏主键（密集索引）
		非主键索引存储相关键位和其对应的主键值，包含两次查找
		

在mysql目录的data/库名 目录下 ，会有表对应的文件
表结构是 ：表名.frm
InnoDB 的表有2个文件 一个是 frm 一个是 表名.ibd 是数据和索引
myisam 的表有3个文件 一个是 frm 还有 .MID .MYI 分别是数据和索引

图解

• innodb使用的是密集索引，将主键组织到一颗B+tree中，行数据就存储在叶子节点上。因为innoDB的主键索引和对应的数据是保存在同一个文件当中的，所以检索的时候在加载叶子节点的主键进入内存的同时也加载了对应的数据，即若使用where id=14这样的条件查询主键，则按照B+tree的检索算法，即可查找到对应的叶子节点，并获得对应的行数据。
  若对稀疏索引进行条件筛选，则需要经历两个步骤，第一步：在稀疏索引的B+tree中检索该键，比如说检索Ellison，就定位到这个主键信息。第二步，也不就是使用这个主键where id=14在b+tree中再执行一遍我们B+tree的检索操作，最终在到达叶子节点获取整行的数据。
• 而myisam使用的均为稀疏索引，对MyISAM 来说, 主键索引和其他索引没有任何区别, 都是稀疏索引 , 表数据存储在独立的地方, 表数据和索引的分开的, 索引用地址指向表数据，稀疏索引的两颗B+tree看上去没有什么不同，节点的结构完全一致，只是存储的内容不一样而已。主键索引B+tree的节点的存储了主键，辅助键索引B+tree存储辅助键，表数据存储在独立的地方，即主键和他的数据是分开存储的。这两个B+tree的叶子节点都使用一个地址指向真正的表数据，对于表数据来说这两个键没有任何差别。由于所以树是独立的，通过辅助键检索无需访问主键的索引树。

一个例题深入理解

之所以使用了这个索引，是因为查询优化器来做的决定，Mysql的查询优化器最重要的目标是尽可能的使用索引，并且使用最严格的索引来消除尽可能多的数据行，最终目标是提交select语句查找数据行，而不是排除数据行。优化器试图排除数据行的原因在于他排除数据行的速度越快，那么找到条件匹配的数据行也就越快，因此查询优化器会根据一些分析和判断的标准决定使用哪一个索引，这里没有选择主键索引，大致原因是由于密集索引的叶子节点把其他列的数据也存放到了叶子节点当中，这里变成主键索引的一个缺点了，这样就影响了查询效率，因为我们数据都放在一起，会比稀疏索引要低。为什么？因为毕竟，稀疏索引只存储了关键字以及主键的值，这样在内存里面就能加载更多的关键字和主键的值去做count()操作了，解决了性能，所以，查询优化器就选择“account”非主键索引。

索引分类

• 单值索引 ：即一个索引只包含单个列，一个表可以有多个单列索引
• 唯一索引 ：索引列的值必须唯一，但允许有空值
• 复合索引 ：即一个索引包含多个列

索引语法

索引在创建表的时候，可以同时创建， 也可以随时增加新的索引。

CREATE 	[UNIQUE|FULLTEXT|SPATIAL]  INDEX index_name 
[USING  index_type]
ON tbl_name(index_col_name,...)

index_col_name : column_name[(length)][ASC | DESC]

# 查看索引
show index  from  table_name;

# 删除索引
DROP  INDEX  index_name  ON  tbl_name;

# 该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL
alter  table  tb_name  add  primary  key(column_list); 

# 这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）	
alter  table  tb_name  add  unique index_name(column_list);
	
# 添加普通索引， 索引值可以出现多次。	
alter  table  tb_name  add  index index_name(column_list);
	
# 该语句指定了索引为FULLTEXT， 用于全文索引	
alter  table  tb_name  add  fulltext  index_name(column_list);	

# idx_city_name 是索引名，city 是表名 ，city_name是索引字段
create index idx_city_name on city(city_name);

索引设计原则

​ 索引的设计可以遵循一些已有的原则，创建索引的时候请尽量考虑符合这些原则，便于提升索引的使用效率，更高效的使用索引。

• 对查询频次较高，且数据量比较大的表建立索引。

• 索引字段的选择，最佳候选列应当从where子句的条件中提取，如果where子句中的组合比较多，那么应当挑选最常用、过滤效果最好的列的组合。

• 使用唯一索引，区分度越高，使用索引的效率越高。

• 索引可以有效的提升查询数据的效率，但索引数量不是多多益善，索引越多，维护索引的代价自然也就水涨船高。对于插入、更新、删除等DML操作比较频繁的表来说，索引过多，会引入相当高的维护代价，降低DML操作的效率，增加相应操作的时间消耗。另外索引过多的话，MySQL也会犯选择困难病，虽然最终仍然会找到一个可用的索引，但无疑提高了选择的代价。

• 使用短索引，索引创建之后也是使用硬盘来存储的，因此提升索引访问的I/O效率，也可以提升总体的访问效率。假如构成索引的字段总长度比较短，那么在给定大小的存储块内可以存储更多的索引值，相应的可以有效的提升MySQL访问索引的I/O效率。

• 利用最左前缀，N个列组合而成的组合索引，那么相当于是创建了N个索引，如果查询时where子句中使用了组成该索引的前几个字段，那么这条查询SQL可以利用组合索引来提升查询效率。

创建复合索引:
	CREATE INDEX idx_name_email_status ON tb_seller(NAME,email,STATUS);
就相当于
	对name 创建索引 ;
	对name , email 创建了索引 ;
	对name , email, status 创建了索引 ;

---

本文参考www.itheima.com学习资料，只用于本人学习笔记总结，不可转载，如有侵权请谅解。