索引的类型和存储引擎有关,每种存储引擎所支持的索引类型不一定完全相同。MySQL 中的索引,可以从存储方式、使用逻辑和实际使用等不同角度来进行分类
I/O 消耗,相对于内存存取的消耗,I/O 存取的消耗要更高。所以评价索引的优劣最重要的指标,就是在查找过程中磁盘 I/O 操作次数的复杂度,而索引的本质都是基于某种数据结构来设计的,所以,索引的数据结构要尽量减少查找过程中磁盘 I/O 的存取次数MySQL 中常用的索引,在物理上分为 B+Tree 索引 和 HASH 索引两类,两种不同类型的索引各有其不同的适用范围B+Tree 是BTree 的一种特殊变种

假设要从图中查找id = X的数据,BTREE 搜索过程如下:
40和60两个关键字。X = 40,则命中;如果X < 40走P1;如果40 < X < 60走P2;如果X = 60,则命中;如果X > 60走P3。B+Tree 在原有 BTree 的基础上补充了如下特性:
B+Tree 根节点和支节点没有数据区,数据data全部存储在叶子节点中;
假设为字段ID添加索引,搜索X = 1的数据,**B+TREE** 搜索过程如下:
1,28,66三个关键字。X <= 1 走P1,取出磁盘块,加载1,10,20三个关键字。X <= 1 走P1,取出磁盘块,加载1, 8, 9三个关键字。1,加载对应数据节点BTree的数据(或指向数据的指针)存在每个节点里,而 B+Tree的数据(或指向数据的指针)仅存在叶子节点里,非叶子节点只有索引。BTree 的查找,可能会在任意一个节点停止,而 B+Tree的查找相对稳定。B+Tree 的非叶子节点可以存储更多的索引值,阶数更高B+Tree 的叶子节点使用双向链表链接,提高顺序查询效率BTree , B+Tree 在区间查找方面更胜一筹B+Tree**全表扫描能力更强。**如果我们要根据索引去进行数据表的扫描,如果基于BTREE进行扫描,需要把整棵树遍历一遍,而B+TREE只需要遍历所有叶子节点即可(叶子节点之间形成有序列表)。B+Tree排序能力更强B+TREE**磁盘读写能力更强。**他的根节点和枝节点不保存数据区,所以根节点和枝节点同样大小的情况下,保存的关键字要比BTREE要多。所以,B+TREE读写一次磁盘加载的关键字比BTREE更多。B+Tree查询性能稳定。B+Tree数据只保存在叶子节点,每次查询数据,查询IO次数一定是稳定的HASH 索引。MySQL 目前仅有 MEMORY存储引擎和 HEAP存储引擎支持这类索引。key)通过哈希算法,计算该字段的哈希值,用于访问哈希表结构中的对应索引,该索引指向数据行
InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”,当某个索引值被使用的非常频繁时,会在 B+Tree 索引之上再创建一个哈希索引,这样就让 B+Tree 索引具有哈希索引的优点,比如:快速的精准查找根据索引的具体用途,MySQL 中的索引在使用逻辑上分为以下 4 类:
MySQL 中最基本的索引类型,它没有任何限制,唯一任务就是加快系统对数据的访问速度。示例:
在 tb_student 表中的 id 字段上建立名为 index_id 的索引
CREATE INDEX index_id ON tb_student(id);
示例:
在 tb_student 表中的 id 字段上建立名为 index_id 的索引
CREATE UNIQUE INDEX index_id ON tb_student(id);
PRIMARY KEY 关键字。不能使用 CREATE ``INDEX 语句创建主键索引,需要以创建或修改表结构的方式进行添加示例:
在 tb_student 表中的 id 字段上添加主键索引
ALTER TABLE tb_student ADD PRIMARY KEY (id)
CHAR、VARCHAR 或 TEXT 类型的列上创建。全文索引允许在索引列中插入重复值和空值。示例:
在 tb_student 表中的 info 字段上建立名为 index_info 的全文索引
CREATE FULLTEXT INDEX index_info ON tb_student(info);
示例:
在 tb_student 表中的 name 和 address 字段上建立名为 index_na 的索引。该索引创建好了以后,查询条件中必须有 name 字段才能使用索引
CREATE INDEX index_na ON tb_student(name,address);
(c1,c2,c3),在实际查询中,系统用来实际加速的索引有三个:单个索引(c1)、双列索引(c1,c2)和多列索引(c1,c2,c3)