点击链接查看数据库其他内容：
MySQL索引 目录
3 MySQL索引
3.1 索引是什么
索引的创建是需要消耗时间的。
有索引的查询和没有索引的查询相比，效率相差几十倍。
数据库索引，是数据库管理系统（DBMS）中一个排序的数据结构，以协助快速查询、更新数据库表中数据。
3.1.1 索引介绍
数据是以文件的形式存放在磁盘上面的，每一行数据都有它的磁盘地址。如果没有索引的话，我们要从 500 万行数据里面检索一条数据，只能依次遍历这张表的全部数据（循环调用存储引擎的读取下一行数据的接口），直到找到这条数据。——全表扫描。
但是有了索引之后，只需要在索引里面去检索这条数据就行了，因为它是一种特殊的专门用来快速检索的数据结构，我们找到数据存放的磁盘地址以后，就可以拿到数据了。
3.1.2 索引类型
怎么创建一个索引？
可以在建表的时候指定，或者 alter table，也可以使用工具。
在 InnoDB 中，索引类型有三种，普通索引、唯一索引（主键索引是特殊的唯一索引）、全文索引。
普通（Normal）：也叫非唯一索引，是最普通的索引，没有任何的限制。
唯一（Unique）：唯一索引要求键值不能重复。另外需要注意的是，主键索引是一种特殊的唯一索引，它还多了一个限制条件，要求键值不能为空。主键索引用 primay key创建。
全文（Fulltext）：针对比较大的数据，比如我们存放的是消息内容，有几 KB 的数据的这种情况，如果要解决 like 查询效率低的问题，可以创建全文索引。只有文本类型的字段才可以创建全文索引，比如 char、varchar、text。
create table m3 (name varchar(50),fulltext index(name));
select * from fulltext_test where match(content) against('text' IN NATURAL LANGUAGE MODE);上面的语句中，创建索引时，fulltext index 与 fulltext key是等价的。
3.2 索引存储结构
3.2.1 索引存储结构分析
（1）可以考虑用有序数组作为索引的数据结构。
有序数组的等值查询和比较查询效率非常高，但是更新数据的时候会出现一个问题，可能要挪动大量的数据（改变 index），所以只适合存储静态的数据。
（2）链表
为了支持频繁的修改，比如插入数据，我们需要采用链表。链表的话，如果是单链表，它的查找效率还是不够高。
所以，有没有可以使用二分查找的链表呢？为了解决这个问题，BST（Binary Search Tree）即二叉查找树诞生了。
（3）二叉查找树（T BST y Binary h Search Tree
左子树所有的节点都小于父节点，右子树所有的节点都大于父节点。投影到平面以后，就是一个有序的线性表。
二叉查找树既能够实现快速查找，又能够实现快速插入。
但是二叉查找树有一个问题：
就是它的查找耗时是和这棵树的深度相关的，在最坏的情况下（斜树中）时间复杂度会退化成O(n)。
因为左右子树深度差太大，这棵树的左子树根本没有节点——也就是它不够平衡。
所以，有没有左右子树深度相差不是那么大，更加平衡的树呢？
这个就是平衡二叉树，叫做 Balanced binary search trees，或者 AVL 树。
（4）平衡二叉树（AVL Tree）
平衡二叉树的定义：左右子树深度差绝对值不能超过 1。
比如左子树的深度是 2，右子树的深度只能是 1 或者 3。
为了保持平衡，AVL 树在插入和更新数据的时候执行了一系列的计算和调整的操作。（自动左旋、右旋）
在平衡二叉树中，一个节点，它的大小是一个固定的单位，作为索引应该存储什么内容？
它应该存储三块的内容：
第一个是索引的键值。比如我们在 id 上面创建了一个索引，我在用 where id =1 的条件查询的时候就会找到索引里面的 id 的这个键值。
第二个是数据的磁盘地址，因为索引的作用就是去查找数据的存放的地址。
第三个，因为是二叉树，它必须还要有左子节点和右子节点的引用，这样我们才能找到下一个节点。比如大于 26 的时候，走右边，到下一个树的节点，继续判断。
当我们用树的结构来存储索引的时候，因为拿到一块数据就要在 Server 层比较是不是需要的数据，如果不是的话就要再读一次磁盘。
访问一个节点就要跟磁盘之间发生一次 I/O。InnoDB 操作磁盘的最小的单位是一页（或者叫一个磁盘块），大小是 16K(16384 字节)。
那么，一个树的节点就是 16K 的大小。如果我们一个节点只存一个键值+数据+引用，例如整形的字段，可能只用了十几个或者几十个字节，它远远达不到 16384 字节的容量，所以访问一个树节点，进行一次 IO的时候，浪费了大量的空间。
所以如果每个节点存储的数据太少，从索引中找到我们需要的数据，就要访问更多的节点，意味着跟磁盘交互次数就会过多，消耗的时间也越多。
所以解决方案是什么呢？
第一个，就是让每个节点存储更多的数据。
第二个，让每一层有更多的节点。也就是增加分叉数（或者路数），每个节点放更
多的指针。
这样的话，就会极大地降低树的深度。我们的树就从原来的高瘦高瘦的样子，变成了矮胖矮胖的样子。
这个时候，我们的树就不再是二叉了，而是多叉，或者叫做多路。
（5）多路平衡查找树（B Tree）（分裂、合并）
跟 AVL 树一样，B 树在枝节点和叶子节点存储键值、数据地址、节点引用。
它有一个特点：分叉数（路数）永远比关键字数多 1。比如我们画的这棵树，每个节点存储两个关键字，那么就会有三个指针指向三个子节点。
在更新索引的时候会有大量的索引的结构的调整，所以解释了为什么不要在频繁更新的列上建索引，或者为什么不要更新主键。
节点的分裂和合并，其实就是 InnoDB 页（page）的分裂和合并
（6）B+树（加强版多路平衡查找树）
总体上来说，这个 B 树的改良版本解决的问题比 B Tree 更全面。
InnoDB 里面的 B+树的存储结构：
MySQL 中的 B+Tree 有两个特点：
1、它的关键字的数量是跟路数相等的；
2、B+Tree 的根节点和枝节点中都不会存储数据，只有叶子节点才存储数据。
目前的认知：我们这要存放的数据是什么？是不是真实数据的地址？
搜索到关键字不会直接返回，会到最后一层的叶子节点。比如我们搜索 id=28，虽然在第一层直接命中了，但是数据地址在叶子节点上面，所以我还要继续往下搜索，一直到叶子节点。
3、B+Tree 的每个叶子节点增加了一个指向相邻叶子节点的指针，它的最后一个数据会指向下一个叶子节点的第一个数据，形成了一个有序链表的结构。
【重要】InnoDB 中的 B+Tree 这种特点带来的优势：
1)它是 B Tree 的变种，B Tree 能解决的问题，它都能解决。B Tree 解决的两大问题是什么？（每个节点存储更多关键字；路数更多）
2)扫库、扫表能力更强（如果我们要对表进行全表扫描，只需要遍历叶子节点就可以了，不需要遍历整个B+Tree 拿到所有的数据）
3) B+Tree 的磁盘读写能力相对于 B Tree 来说更强（根节点和枝节点不保存数据区，所以一个节点可以保存更多的关键字，一次磁盘加载的关键字更多）
4)排序能力更强（因为叶子节点上有下一个数据区的指针，数据形成了链表）
5)效率更加稳定（B+Tree 永远是在叶子节点拿到数据，所以 IO 次数是稳定的）
3.2.2 索引方式
在 Navicat 的工具中，创建索引，索引方式有两种。
HASH：以 KV 的形式检索数据，也就是说，它会根据索引字段生成哈希码和指针，指针指向数据。
哈希索引有什么特点呢？
第一个，它的时间复杂度是 O(1)，查询速度比较快。但是哈希索引里面的数据不是按顺序存储的（无序存储的），所以不能用于排序。
第二个，我们在查询数据的时候要根据键值计算哈希码，所以它只能支持等值查询（= IN），不支持范围查询（> < >= <= between and）。
第三：如果字段重复值很多的时候，会出现大量的哈希冲突（采用拉链法解决），效率会降低。
需要注意的是，在 InnoDB 中，不能显示地创建一个哈希索引（所谓的支持哈希索引指的是 Adaptive Hash Index）。
memory 存储引擎可以使用 Hash 索引。
CREATE TABLE `user_memory` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`gender` tinyint(1) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING HASH
) ENGINE=MEMORY AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4;【面试】索引存储结构为什么不用红黑树？
(1)系统从磁盘中读取数据是以磁盘块（block）为单位的,位于同一磁盘的数据都会被读取出来而不是需要什么就读取什么。
InnoDB引擎是以页为磁盘管理的最小单位，默认大小为16k,当然也可以自己调整，而磁盘中的块往往没有这么大的空间，所用InnoDB一般会申请连续的多个块来达到页的大小16k。数据库系统通常将索引的一个节点设置为一个页的大小，这样每个节点只需一次I/O就可以完全载入。如果数据不在同一个磁盘上，那么通常需要移动磁臂来寻找柱面，效率低下。
（2）因为B+树非页节点都用来存储键值，数据都存储在叶节点中，所以当数据库记录很多时，B+树的深度也不会很大，所以I/O查询次数也不会很多最多h-1次（根节点常驻内存）。B+ 树相对于红黑树有更低的树高，进行寻道的次数与树高成正比，在同一个磁盘块上进行访问只需要很短的磁盘旋转时间，所以 B+ 树更适合磁盘数据的读取。
在大规模数据存储的时候，红黑树往往出现由于树的深度过大而造成磁盘IO读写过于频繁，进而导致效率低下的情况。
（由于 B+ 树分支比二叉树更多，所以相同数量的内容，B+ 树的深度更浅，深度代表什么？代表磁盘 io 次数啊！）
【补充】数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的，在实际实现B-Tree还需要使用如下技巧：每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。
【因为B Tree和B+Tree的特性，它们广泛地用在文件系统和数据库中，例如Windows的 HPFS 文件系统，Oracel、MySQL、SQLServer 数据库。】
3.3 B+Tree落地形式
主要介绍MyISAM和InnoDB。
每张 InnoDB 的表有两个文件（.frm 和.ibd），MyISAM 的表有三个文件（.frm、.MYD、.MYI）。有一个是相同的文件，.frm。 .frm 是 MySQL 里面表结构定义的文件，不管你建表的时候选用任何一个存储引擎都会生成，我们就不看了。我们主要看一下其他两个文件是怎么实现 MySQL 不同的存储引擎的索引的。
3.3.1 MyISAM
在 MyISAM 里面，另外有两个文件：
一个是.MYD 文件，D 代表 Data，是 MyISAM 的数据文件，存放数据记录，比如我们的 user_myisam 表的所有的表数据。
一个是.MYI 文件，I 代表 Index，是 MyISAM 的索引文件，存放索引，比如我们在id 字段上面创建了一个主键索引，那么主键索引就是在这个索引文件里面。
也就是说，在 MyISAM 里面，索引和数据是两个独立的文件。
MyISAM 的 B+Tree 里面，叶子节点存储的是数据文件对应的磁盘地址。所以从索引文件.MYI 中找到键值后，会到数据文件.MYD 中获取相应的数据记录。
在 MyISAM 里面，辅助索引也在这个.MYI 文件里面。
辅助索引跟主键索引存储和检索数据的方式是没有任何区别的，一样是在索引文件里面找到磁盘地址，然后到数据文件里面获取数据。
3.3.2 InnoDB
InnoDB 只有一个文件（.ibd 文件）。
在 InnoDB 里面，它是以主键为索引来组织数据的存储的，所以索引文件和数据文件是同一个文件，都在.ibd 文件里面。在 InnoDB 的主键索引的叶子节点上，它直接存储了我们的数据。
所以，在 InnoDB 中索引即数据，数据即索引，就是这个原因。
InnoDB的主键索引只有一个。
主键的顺序决定了数据的顺序。
（1）聚集索引（聚簇索引）——主键索引
就是索引键值的逻辑顺序跟表数据行的物理存储顺序是一致的。（比如字典的目录是按拼音排序的，内容也是按拼音排序的，按拼音排序的这种目录就叫聚集索引）。
InnoDB组织数据的方式就是（聚集）索引组织表（clustered index organize table）。
如果说一张表创建了主键索引，那么这个主键索引就是聚集索引，决定数据行的物理存储顺序。
（2）二级索引（辅助索引）
没有主键索引怎么办？
他们存储什么内容，他们的叶子节点上没有数据怎么检索完整数据？
二级索引存储的是辅助索引的键值，例如在 name 上建立索引，节点上存的是 name的值，qingshan mic tom 等等。而二级索引的叶子节点存的是这条记录对应的主键的值。
要遍历两颗B+Tree。
所以，二级索引检索数据的流程是这样的：
当 我 们 用 name 索 引 查 询 一 条 记 录 ， 它 会 在 二 级 索 引 的 叶 子 节 点 找 到name=qingshan，拿到主键值，也就是 id=1，然后再到主键索引的叶子节点拿到数据。从这个角度来说，因为主键索引比二级索引少扫描了一棵 B+Tree，它的速度相对会快一些。
（3）没有主键索引或是没有索引
1、如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
2、如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引（unique key）作为主键索引。
3、如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。
3.3 索引使用原则
3.3.1 列的离散度（选择度）
第一个叫做列的离散度，我们先来看一下列的离散度的公式：
count(distinct(column_name)) : count(*)
列的全部不同值和所有数据行的比例。数据行数相同的情况下，分子越大，列的离散度就越高。
简单来说，如果列的重复值越多，离散度就越低，重复值越少，离散度就越高。
不建议在离散度低的字段上建立索引。
没有索引的时候查一遍：
3.3.2 联合索引最左匹配
前面我们说的都是针对单列创建的索引，但有的时候我们的多条件查询的时候，也会建立联合索引，举例：查询成绩的时候必须同时输入身份证和考号。
单列索引可以看成是特殊的联合索引。比如我们在 user 表上面，给 name 和 phone 建立了一个联合索引。
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);联合索引在 B+Tree 中是复合的数据结构，它是按照从左到右的顺序来建立搜索树的（name 在左边，phone 在右边）。
从这张图可以看出来，name 是有序的，phone 是无序的。当 name 相等的时候，phone 才是有序的。
这个时候我们使用 where name='zzz' and phone = '136xx'去查询数据的时候，B+Tree 会优先比较 name 来确定下一步应该搜索的方向，往左还是往右。
如果 name相同的时候再比较 phone。但是如果查询条件没有 name，就不知道第一步应该查哪个节点，因为建立搜索树的时候 name 是第一个比较因子，所以用不到索引。（即使用phone来查询时，无法使用联合索引）
EXPLAIN SELECT * FROM user_innodb WHERE phone = '13677338899';【必须要从最左边开始，并且中间不能中断】
(1)什么时候用到联合索引
在建立联合索引的时候，一定要把最常用的列放在最左边。
设置联合索引 com_a_b_c (在a b c 三个属性上建立了联合索引)
（2）如何创建联合索引
项目里面有两个查询很慢，按照我们的想法，一个查询创建一个索引，所以我们针对这两条 SQL 创建了两个索引，这种做法觉得正确吗？
CREATE INDEX idx_name on user_innodb(name);
CREATE INDEX idx_name_phone on user_innodb(name,phone);当创建一个联合索引的时候，按照最左匹配原则，用左边的字段 name 去查询的时候，也能用到索引，所以第一个索引完全没必要。相当于建立了两个联合索引(name),(name,phone)。
如果创建三个字段的索引 index(a,b,c)，相当于创建三个索引：
index(a)
index(a,b)
index(a,b,c)ll
用 where b=? 和 where b=? and c=? 是不能使用到索引的。
3.3.3 覆盖索引（重要）
（1）回表
非主键索引，我们先通过索引找到主键索引的键值，再通过主键值查出索引里面没有的数据，它比基于主键索引的查询多扫描了一棵索引树，这个过程就叫回表。
（2）覆盖索引
在辅助索引里面，不管是单列索引还是联合索引，如果 select 的数据列只用从索引中就能够取得，不必从数据区中读取，这时候使用的索引就叫做覆盖索引，这样就避免了回表。
Extra 里面值为“Using index”代表使用了覆盖索引。
（3）示例
首先创建一个联合索引：
-- 创建联合索引
ALTER TABLE user_innodb DROP INDEX comixd_name_phone;
ALTER TABLE user_innodb add INDEX `comixd_name_phone` (`name`,`phone`);以下语句都用到了覆盖索引：
EXPLAIN SELECT name,phone FROM user_innodb WHERE name= '青山' AND phone = ' 13666666666';
EXPLAIN SELECT nameFROM user_innodb WHERE name= '青山' AND phone = ' 13666666666';
EXPLAIN SELECT phone FROM user_innodb WHERE name= '青山' AND phone = ' 13666666666';select * ，此处用不到覆盖索引。
而有一种特殊情况，虽然没有使用联合索引，但经过优化器的匹配，使用了覆盖索引，从而提升效率。
EXPLAIN SELECT phone FROM user_innodb WHERE phone = ' 13666666666';很明显，因为覆盖索引减少了 IO 次数，减少了数据的访问量，可以大大地提升查询效率。
3.4 索引的创建与使用
因为索引对于改善查询性能的作用是巨大的，所以我们的目标是尽量使用索引。
3.4.1 创建索引原则
1、在用于 where 判断 order 排序和 join 的（on）字段上创建索引
2、索引的个数不要过多。——浪费空间，更新变慢。
3、区分度低（散列值低）的字段，例如性别，不要建索引。——离散度太低，导致扫描行数过多。
4、频繁更新的值，不要作为主键或者索引。——页分裂（不要更新主键）
5、随机无序的值，不建议作为主键索引，例如身份证、UUID。——无序，分裂
6、创建联合索引，而不是修改单列索引；联合索引把散列值高（区分度高）的值放在前面。
过长的索引（url/text）：
可以创建前缀索引。（综合考虑前缀的长度与存储空间）
3.4.2 什么时候导致索引失效（重要）
1、索引列上使用函数（replace \ SUBSTR \ CONCAT \ sum count avg）、表达式计算（+ - * /）： https://www.runoob.com/mysql/mysql-functions.html
explain SELECT * FROM `t2` where id+1 = 4;2、字符串不加引号，出现隐式转换
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);
explain SELECT * FROM `user_innodb` where name = 136;
explain SELECT * FROM `user_innodb` where name = '136';3、like 条件中前面带%
where 条件中 like abc%，like %2673%，like %888 都用不到索引吗？为什么？
explain select *from user_innodb where name like 'wang%';
explain select *from user_innodb where name like '%wang';过滤的开销太大。这个时候可以用全文索引。
4、负向查询
NOT LIKE 不能：
explain select *from employees where last_name not like 'wang'!= （<>）和 NOT IN 在某些情况下可以：
explain select *from employees where emp_no not in (1)
explain select *from employees where emp_no <> 1注意跟数据库版本、数据量、数据选择度都有关系。
其实，用不用索引，最终都是优化器（optimizer）说了算。
优化器是基于什么的优化器？
基于 cost 开销（Cost Based Optimizer——简称为CBO），它不是基于规则（Rule-Based Optimizer），也不是基于语义。怎么样开销小就怎么来。
使用索引有基本原则，但是没有具体细则，没有什么情况一定用索引，什么情况一定不用索引的规则。