索引（index）是帮助 MySQL 高效获取数据的数据结构(有序)。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引
索引结构
由于 MySQL（5.5之后）默认的存储引擎是 InnoDB， 而 InnoDB 默认使用 B+Tree索引，所以这节主要讲述 B+Tree 索引，除此之外，还简要介绍一下 Hash，从而论述为什么 InnoDB 存储引擎选择使用 B+Tree 索引结构?
B-Tree
在介绍 B+Tree 之前，我们先来了解一下 B-Tree，B树是一种多叉路衡查找树，相对于二叉树，B树每个节点可以有多个分支，即多叉。
以一颗最大度数（max-degree）为5(5阶)的b-tree为例，那这个B树每个节点最多存储4个key，5个指针：
我们可以通过一个数据结构可视化的网站来简单演示一下： https://www.cs.usfca.edu/~galles/visualization/BTree.html
通过演示可以发现其插入数据满足的特点：
- 5阶的B树，每一个节点最多存储4个key，对应5个指针
- 一旦节点存储的key数量到达5，就会裂变，中间元素向上分裂
- 在B树中，非叶子节点和叶子节点都会存放数据
B+Tree
B+Tree是B-Tree的变种，我们以一颗最大度数（max-degree）为4（4阶）的b+tree为例，来看一下其结构示意图：
这里也可以通过一个数据结构可视化的网站来简单演示一下： https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html
从两者演示和上述两张图中可以看出B树和B+树两者的异同：
B 树的所有节点既存放键(key) 也存放 数据(data)，而 B+树只有叶子节点存放 key 和 data，其他内节点只存放 key。
B 树的叶子节点都是独立的;B+树的叶子节点有一条引用链指向与它相邻的叶子节点。
B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。
MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的 B+Tree，提高区间访问的性能，利于排序
在 MySQL 中，MyISAM 引擎和 InnoDB 引擎都是使用 B+Tree 作为索引结构，但是，两者的实现方式不太一样。
MyISAM 引擎中，B+Tree 叶节点的 data 域存放的是数据记录的地址。在索引检索的时候，首先按照 B+Tree 搜索算法搜索索引，如果指定的 Key 存在，则取出其 data 域的值，然后以 data 域的值为地址读取相应的数据记录。这被称为“非聚簇索引（非聚集索引）”。
InnoDB 引擎中，其数据文件本身就是索引文件。相比 MyISAM，索引文件和数据文件是分离的，其表数据文件本身就是按 B+Tree 组织的一个索引结构，树的叶节点 data 域保存了完整的数据记录。这个索引的 key 是数据表的主键，因此 InnoDB 表数据文件本身就是主索引。这被称为“聚簇索引（聚集索引）”，而其余的索引都作为 辅助索引 ，辅助索引的 data 域存储相应记录主键的值而不是地址，这也是和 MyISAM 不同的地方。在根据主索引搜索时，直接找到 key 所在的节点即可取出数据；在根据辅助索引查找时，则需要先取出主键的值，再走一遍主索引。 因此，在设计表的时候，不建议使用过长的字段作为主键，也不建议使用非单调的字段作为主键，这样会造成主索引频繁分裂
Hash索引
哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中。如果两个(或多个)键值，映射到一个相同的槽位上，他们就产生了hash冲突（也称为hash碰撞），可以通过链表来解决，如下图所示：
Hash索引的特点：
- Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，…）
- 无法利用索引完成排序操作
- 查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引
思考题： 为什么 InnoDB 存储引擎选择使用 B+tree 索引结构?
- 相对于二叉树，层级更少，搜索效率高
- 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低
- 相对Hash索引，B+tree支持范围匹配及排序操作
索引分类
应用维度
在 MySQL 数据库，将索引的具体类型主要分为以下几类：主键索引、唯一索引、常规索引、全文索引
- 主键索引：针对表中主键创建的索引（PRIMARY），加速查询 + 列值唯一（不可以有 NULL）+ 表中只有一个
- 唯一索引：避免同一个表中某数据列中的值重复（UNIQUE），加速查询 + 列值唯一（可以有 NULL）
- 普通索引：仅加速查询
- 全文索引：对文本的内容进行分词，进行搜索（FULLTEXT）。目前只有
CHAR、VARCHAR，TEXT列上可以创建全文索引。一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替
底层存储方式
在 InnoDB 存储引擎中，根据索引的存储形式，又可以分为以下两种：
- 聚集索引：将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据（必须有，而且只有一个）
- 二级索引：将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键（可以存在多个）
聚集索引选取规则:
- 如果存在主键，主键索引就是聚集索引
- 如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引
- 如果表没有主键，或没有合适的唯一索引，则 InnoDB 会自动生成一个某一行的 id 作为隐藏的聚集索引
接下来，我们可以通过下图了解当我们执行如下的 SQL 语句时，查找过程是什么样子的
- 聚集索引的叶子节点下挂的是这一行的数据
- 二级索引的叶子节点下挂的是该字段值对应的主键值
- 回表查询：先到二级索引中查找数据，找到主键值，然后再到聚集索引中根据主键值，获取数据的方式
索引语法
创建索引
CREATE [UNIQUE | FULLTEXT] INDEX index_name ON table_name (index_col_name,...);查看索引
SHOW INDEX FROM table_name;删除索引
DROP INDEX index_name ON table_name;
SQL性能分析
SQL执行频率
MySQL 客户端连接成功后，通过 show [session|global] status 命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次：
-- session 是查看当前会话 ;
-- global 是查询全局数据 ;
SHOW GLOBAL STATUS LIKE 'Com_______';- Com_delete: 删除次数
- Com_insert: 插入次数
- Com_select: 查询次数
- Com_update: 更新次数
慢查询日志
慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有 SQL 语句的日志。
MySQL 的慢查询日志默认没有开启，我们可以查看一下系统变量 slow_query_log
show variables like 'show_query_log';如果要开启慢查询日志，需要在 MySQL 的配置文件（/etc/my.cnf）中配置如下信息：
# 开启MySQL慢日志查询开关
slow_query_log=1
# 设置慢日志的时间为2秒，SQL语句执行时间超过2秒，就会视为慢查询，记录慢查询日志
long_query_time=2配置完毕之后，通过以下指令重新启动 MySQL 服务器进行测试
systemctl restart mysqld然后再次查看开关情况，慢查询日志就已经打开了
查看慢日志文件中记录的信息：tail -f /var/lib/mysql/localhost-slow.log
profile详情
show profiles 能够在做 SQL 优化时帮助我们了解时间都耗费到哪里去了。通过 have_profiling 参数，能够看到当前 MySQL 是否支持 profile 操作：
SELECT @@have_profiling ;MySQL 是支持 profile 操作的，但是开关是关闭的，可以通过 set 语句在 session/global 级别开启profiling：
SET profiling = 1;执行一系列的业务 SQL 的操作，可以通过如下指令查看指令的执行耗时：
-- 查看每一条SQL的耗时基本情况
show profiles;
-- 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
-- 查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;explain
EXPLAIN 或者 DESC命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序
语法：EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件;
Explain 执行计划中各个字段的含义:
| 字段 | 含义 |
|---|---|
| id | select查询的序列号，表示查询中执行select子句或者是操作表的顺序 (id相同，执行顺序从上到下；id不同，值越大，越先执行)。 |
| select_type | 表示 SELECT 的类型，常见的取值有 SIMPLE（简单表，即不使用表连接 或者子查询）、PRIMARY（主查询，即外层的查询）、 UNION（UNION 中的第二个或者后面的查询语句）、 SUBQUERY（SELECT/WHERE之后包含了子查询）等 |
| type | 表示连接类型，性能由好到差的连接类型为NULL、system、const、 eq_ref、ref、range、 index、all 。 |
| possible_key | 显示可能应用在这张表上的索引，一个或多个。 |
| key | 实际使用的索引，如果为NULL，则没有使用索引。 |
| key_len | 表示索引中使用的字节数， 该值为索引字段最大可能长度，并非实际使用长 度，在不损失精确性的前提下， 长度越短越好 。 |
| rows | MySQL 认为必须要执行查询的行数，在 innodb 引擎的表中，是一个估计值， 可能并不总是准确的。 |
| filtered | 表示返回结果的行数占需读取行数的百分比， filtered 的值越大越好。 |
| Extra | 含义 |
|---|---|
| Using where; Using Index | 查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据 |
| Using index condition | 查找使用了索引，但是需要回表查询数据 |
索引使用
索引失效情况
最左前缀法则
如果索引了多列（联合索引），要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。如果跳跃某一列，索引将会部分失效(后面的字段索引失效)
范围查询
联合索引中，出现范围查询(>,<)，范围查询右侧的列索引失效，但使用(>= ,<=) 不会失效。因此，在业务允许的情况下，尽可能的使用类似于 >= 或 <= 这类的范围查询，而避免使用 > 或 <
索引列计算
在索引列上进行运算操作， 索引将失效。如我们在 tb_user 这张表中 phone 字段建立了索引，当根据 phone 字段进行函数运算操作之后，索引失效，当我们执行以下语句时，发现 key 字段为 NULL，即索引失效
explain select * from tb_user where substring(phone,10,2) = '15';字符串不加引号
字符串类型字段使用时，不加引号，索引将失效，同上，当我们执行以下语句时，也会发现 key 字段为 NULL，索引失效
explain select * from tb_user where phone = 17799990015;模糊查询
如果仅仅是尾部模糊匹配，索引不会失效。如果是头部模糊匹配，索引失效
like '软件%' 索引不失效，like '%工程'索引失效
连接条件or
用or分割开的条件， 如果 or 前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到，当我们使用 or 连接时，只有左右两侧字段都有索引时，索引才会生效
数据分布影响
如果 MySQL 评估使用索引比全表更慢，则不使用索引
SQL提示
SQL提示，是优化数据库的一个重要手段，简单来说，就是在SQL语句中加入一些人为的提示来达到优化操作的目的
use index ： 建议 MySQL 使用哪一个索引完成此次查询（仅仅是建议，mysql 内部还会再次进行评估）
explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';ignore index ： 忽略指定的索引
explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';force index ： 强制使用索引
explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';索引设计原则
先介绍几个名词意思
覆盖索引：指查询使用了索引，并且需要返回的列，在该索引中已经全部能够找到，查询时尽量使用覆盖索引，减少select *
前缀索引：当字段类型为字符串（varchar，text，longtext等）时，有时候需要索引很长的字符串，这会让索引变得很大，查询时，浪费大量的磁盘IO， 影响查询效率。此时可以只将字符串的一部分前缀，建立索引，这样可以大大节约索引空间，从而提高索引效率
如为 tb_user 表的 email 字段，建立长度为5的前缀索引：create index idx_email_5 on tb_user(email(5));
单列索引：即一个索引只包含单个列
联合索引：即一个索引包含了多个列
设计索引应满足的原则：
- 针对于数据量较大，且查询比较频繁的表建立索引
- 针对于常作为查询条件（where）、排序（order by）、分组（group by）操作的字段建立索引
- 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高
- 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引
- 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率
- 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率
- 如果索引列不能存储NULL值，请在创建表时使用NOT NULL约束它。当优化器知道每列是否包含 NULL 值时，它可以更好地确定哪个索引最有效地用于查询
参考
- 黑马程序员 MySQL 数据库入门到精通
