一、索引概述（P66）
1. 介绍
索引（index）是帮助 MySQL 高效获取数据的数据结构（有序）。
在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是 索引 。
2. 优缺点
二、索引结构
1. 概述
MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的索引结构，主要包含以下几种：
注意： 我们平常所说的索引，如果没有特别指明，都是指 B+ 树结构组织的索引。
2. 二叉树
如果主键是顺序插入的，则会形成一个单向链表。
二叉树缺点：
（1）顺序插入时，会形成一个链表，查询性能大大降低。
（2）大数据量情况下，层级较深，检索速度慢。
红黑树缺点：
（1）大数据量情况下，层级较深，检索速度慢。
3. B-Tree（多路平衡查找树）
知识小贴士 : 树的度数指的是一个节点的子节点个数。
B-Tree ， B 树是一种多叉路衡查找树，相对于二叉树， B 树每个节点可以有多个分支，即多叉。
以一颗最大度数（ max-degree ）为 5(5 阶 ) 的 b-tree 为例，那这个 B 树每个节点最多存储 4 个key，5个指针：
我们可以通过一个数据结构可视化的网站来简单演示一下。 B-Tree Visualization (usfca.edu)
特点：（1）5 阶的 B 树，每一个节点最多存储 4 个 key ，对应 5 个指针。（2）一旦节点存储的 key 数量到达 5 ，就会裂变，中间元素向上分裂。（3）在 B 树中，非叶子节点和叶子节点都会存放数据。
4. B+Tree
B+Tree 是 B-Tree 的变种，我们以一颗最大度数（ max-degree ）为 4（4阶）的b+tree为例，来看一下其结构示意图：
我们可以看到，两部分：（1）绿色框框起来的部分，是 索引部分 ，仅仅起到索引数据的作用，不存储数据。（2）红色框框起来的部分，是 数据存储部分 ，在其叶子节点中要存储具体的数据。
B+Tree 与 B-Tree 相比，主要有以下三点区别：（1）所有的数据都会出现在叶子节点。（2）叶子节点形成一个单向链表。（3）非叶子节点仅仅起到索引数据作用，具体的数据都是在叶子节点存放的。
MySQL 索引数据结构对经典的 B+Tree 进行了优化。在原 B+Tree 的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的 B+Tree，提高区间访问的性能，利于排序。
5. Hash
5.1 结构
哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中。
如果两个(或多个)键值，映射到一个相同的槽位上，他们就产生了hash冲突（也称为hash碰撞），可以通过链表来解决。
5.2 特点
（1）Hash索引只能用于对等比较(=，in)，不支持范围查询（between，>，< ，...）
（2）无法利用索引完成排序操作
（3）查询效率高，通常(不存在hash冲突的情况)只需要一次检索就可以了，效率通常要高于B+tree索引
5.3 存储引擎支持
在 MySQL 中，支持 hash 索引的是 Memory 存储引擎。 而 InnoDB 中具有自适应hash功能，hash索引是 InnoDB 存储引擎根据B+Tree索引在指定条件下自动构建的。
6. 思考题（为什么InnoDB存储引擎选择使用B+tree索引结构?）
（1）相对于二叉树，层级更少，搜索效率高；
（2）对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储
的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低；
（3）相对Hash索引，B+tree支持范围匹配及排序操作；
三、索引分类
1. 索引分类
在MySQL数据库，将索引的具体类型主要分为以下几类：主键索引、唯一索引、常规索引、全文索引。
2. 聚集索引、二级索引
而在在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：
聚集索引选取规则:
（1）如果存在主键，主键索引就是聚集索引。
（2）如果不存在主键，将使用第一个唯一（UNIQUE）索引作为聚集索引。
（3）如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个 rowid 作为隐藏的聚集索引。
（1）聚集索引的叶子节点下挂的是这一行的数据 。
（2）二级索引的叶子节点下挂的是该字段值对应的主键值。
接下来，我们来分析一下，当我们执行如下的 SQL 语句时，具体的查找过程是什么样子的。
具体过程如下 :① . 由于是根据 name 字段进行查询，所以先根据 name='Arm' 到 name字段的二级索引中进行匹配查找。但是在二级索引中只能查找到 Arm 对应的主键值 10 。② . 由于查询返回的数据是 * ，所以此时，还需要根据主键值 10 ，到聚集索引中查找 10对应的记录，最终找到 10 对应的行 row 。③ . 最终拿到这一行的数据，直接返回即可。
回表查询： 这种先到二级索引中查找数据，找到主键值，然后再到聚集索引中根据主键值，获取数据的方式，就称之为回表查询。
3. InnoDB主键索引的B+tree高度为多高呢?
假设:
一页是16K，一行数据大小为 1k ，一页中可以存储 16 行这样的数据。InnoDB 的指针占用 6个字节的空间，主键即使为 bigint ，占用字节数为 8 。
高度为 2 ：n * 8 + (n + 1) * 6 = 16*1024 , 算出 n 约为 11701171* 16 = 18736也就是说，如果树的高度为 2 ，则可以存储 18000 多条记录。
高度为 3 ：1171 * 1171 * 16 = 21939856也就是说，如果树的高度为 3 ，则可以存储 2200w 左右的记录。
四、索引语法
创建索引
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 性能分析
1. SQL 执行频率
MySQL 客户端连接成功后，通过 show [session|global] status 命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次：
-- session 是查看当前会话 ; -- global 是查询全局数据 ; -- 7个下划线代表7个字符 SHOW GLOBAL STATUS LIKE 'Com_______';
Com_delete: 删除次数
Com_insert: 插入次数
Com_select: 查询次数
Com_update: 更新次数
2. 慢查询日志
慢查询日志记录了所有执行时间超过指定参数（long_query_time，单位：秒，默认10秒）的所有 SQL 语句的日志。
MySQL 的慢查询日志默认没有开启，我们可以查看一下系统变量 slow_query_log 。
如果要开启慢查询日志，需要在 MySQL 的配置文件（ /etc/my.cnf ）中配置如下信息：# 开启MySQL慢日志查询开关 slow_query_log=1 # 设置慢日志的时间为2秒，SQL语句执行时间超过2秒，就会视为慢查询，记录慢查询日志 long_query_time=2
配置完毕之后，通过以下指令重新启动 MySQL服务器进行测试，查看慢日志文件中记录的信息【/var/lib/mysql/localhost-slow.log 】systemctl restart mysqld 1
3. profile 详情
show profiles 能够在做 SQL 优化时帮助我们了解时间都耗费到哪里去了。
通过have_profiling 参数，能够看到当前 MySQL 是否支持 profile 操作：SELECT @@have_profiling ;
默认开关是关闭的。可以通过 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;
4. explain
EXPLAIN 或者 DESC 命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序。
语法 :-- 直接在select语句之前加上关键字 explain / desc EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;
Explain 执行计划中各个字段的含义 :
