一、概述
索引是SQL优化的核心
索引(index)是帮助MySQL高效获取数据的数据结构。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种引用(指向数据)，这样可以在这些数据结构上实现高级查找算法，这种数据结构就是索引
下面演示了一条查询语句在有索引(假设维护了一个age二叉排序树)和无索引的情况下的查询效率
索引的优缺点
优点：提高数据检查的效率，降低数据库IO成本
通过索引列对数据进行排序，降低数据排列的成本，降低CPU消耗
缺点：索引列也要占用空间
索引虽然提高了查询效率，但由于要维护索引的数据结构，所以在增删改的时候效率 较低
索引结构默认是B+树索引，所以我们在之后的学习中，也主要学习这种结构
二、索引结构B+树
为什么InnoDB要采用B+树为索引结构
- 对于B-tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低
- 相对于二叉树，层级更少，搜索效率更高
- 相对于Hash索引，B+tree支持范围匹配和排序操作
三、索引分类
在InnoDB存储引擎中，根据索引的存储形式，又可以分为
聚集索引B+树最下面的叶子节点挂的是这一行的数据
二级索引B+树最下面的叶子节点挂的是对应的主键
默认主键索引就是聚集索引
聚集索引：
如果存在主键，主键索引就是聚集索引
如果不存在主键，将使用第一个唯一unique索引作为聚集索引
如果表没有主键，没有合适的唯一索引，InnoDB会自动生成一个rowid作为隐藏的聚集索引
四、思考题
下面两个sql语句，哪一个效率高
id有主键，name字段创建的有索引
select * from user where id=10;
select * from user where name='Arm';答：第一个效率高，因为id是聚集索引，我们直接去聚集索引中去查就可以，而查到的刚好是行数据，可以直接查到
第二个是二级索引，需要先去二级索引中查到对应的id值，然后回表查询(拿着查到的id去聚集索引中去查)，相当于扫描了两个表，所以效率偏低
五、索引语法
查看tb_user表索引
show index from tb_user;
因为name字段可以重复，我们就不能创建唯一索引，所以要创建常规索引
索引名为idx_user_name
create index idx_user_name on tb_user(name);给phone字段创建唯一索引
create unique index idx_user_phone on tb_user(phone);给profession、age、status字段创建联合索引
create index idx_user_pro_age_sta on tb_userr(profession,age,status);给email创建常规索引
create index idx_user_email on tb_user(email);删除索引
drop index 索引名称 on tb_user;六、SQL性能分析工具
我们做SQL性能优化，前提是要知道哪些SQL需要我们去优化，那么SQL性能分析工具就有必要去了解
1. 查看执行频次
查看数据库中哪些类型的sql语句执行频次较高，针对这一类的sql进行优化，会大大提高我们的效率
show global status like 'Com_______'
2. 慢查询日志
我们通过查看sql语句的执行频次，发现select的执行频次较高，那么我们到底针对哪些sql语句进行优化呢?
我们这里会用到慢查询日志来定位到哪些sql执行效率低，从而找到需要优化的sql
慢查询日志记录了所有执行时间超过指定参数(long_query_time，单位：秒，默认10秒)的所有sql语句的日志，MySQL的慢查询日志默认没有开启，需要在MySQL配置文件中(/etc/my.cnf)中配置如下信息：
3. show profiles
执行一些sql语句，然后show profiles，可以看到这些sql语句的执行耗时情况
3. explain执行计划
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
possiable_key：显示可能用在这张表上的索引
key：实际用到的索引
key_len：使用到索引的字节数，长度越短越好
rows：MySQL认为必须要查询的行数，是一个估计值，不准确
filter：返回结果的行数占需要读取行数的百分比
七、索引使用规则
通过上面介绍，根据一个字段查询，这个字段是不是建立了索引，对于查询的时间消耗不是一个数量级的，建立了索引后，查询时间大幅减少。
下面我们将介绍索引的使用规则
1. 最左前缀法则
如果索引了多列(联合索引)，要遵循最左前缀法则。最左前缀法则指的是查询从索引的最左列开始，并且不跳过索引中的列。如果跳跃了某一列，索引将部分失效(后面的索引失效)。
只要最左边的索引存在就可以走索引，跟sql语句中的位置无关
2. 范围查询
联合索引中，出现范围(>，<)，范围查询右侧的列索引失效
要想不失效，在业务允许的范围内，尽量把><替换成>=，<=
3. 索引失效情况
①在索引列上进行运算操作，索引将会失效
②字符串类型使用时，sql语句没加单引号，索引会失效
③模糊查询，头部模糊匹配的时候，索引将会失效
④or分割开的条件，一个有索引，一个没有索引，则涉及的索引都不会被用到
⑤MySQL评估使用索引比全表扫描更慢，则不适用索引
4. SQL提示
SQL提示是优化数据库的一个重要手段，简单来说，就是在sql语句中加入一些人为的提示来达到优化操作的目的
use index 用某个索引(最后MySQL会评估到底用不用，有可能会不采用我们的建议)
ignore index 忽略某个索引(最后MySQL会评估到底用不用，有可能会不采用我们的建议)
force index 强制用某个索引(忽略MySQL评估，强制MySQL用我们的建议)
5. 覆盖索引&回表查询
覆盖索引就是添加索引的字段，覆盖了我们需要查询的字段；如果没有覆盖，那么就会产生回表查询，即先查辅助索引表，再查聚集索引表，性能偏低
所以我们要尽量避免select * 的写法，除非我们把所有的字段都添加了索引
下面一道思考题
6. 单列索引和联合索引
单列索引：即一个索引只包含了单个列
联合索引：即一个索引包含了多个列
在业务场景中，如果存在多个查询条件，考虑针对于查询字段建立索引时，建议建立联合索引，而非单列索引
7. 索引设计原则
- 针对于数据量较大，且查询比较频繁的表建立索引
- 针对于常作为查询条件(where)、排序(order by)、分组 (group by) 操作的字段建立索引。
- 尽量选择区分度高的列作为索引，尽量建立唯一索引，区分度越高，使用索引的效率越高。
- 如果是字符串类型的字段，字段的长度较长，可以针对于字段的特点，建立前缀索引。
- 尽量使用联合索引，减少单列索引，查询时，联合索引很多时候可以覆盖索引，节省存储空间，避免回表，提高查询效率.
- 要控制索引的数量，索引并不是多多益善，索引越多，维护索引结构的代价也就越大，会影响增删改的效率。
- 如果索引列不能存储NUL值，请在创建表时使用NOTNUL约束它。当优化器知道每列是否包含NUL值时，它可以更好地确定哪个索引最有效地用于查询。
