第2章 索引优化分析

１，慢SQL

性能下降、 SQL 慢、执行时间长、等待时间长的原因分析:

1. 查询语句写的烂

2. 索引失效：

   单值索引：在user表中给name属性建个索引，create index idx_user_name on user(name)
   复合索引：在user表中给name、email属性建个索引，create index idx_user_nameEmail on user(name,email)

3. 关联查询太多join(设计缺陷或不得已的需求)

4. 服务器调优及各个参数设置(缓冲、线程数等)

2,join查询

2.1、SQL 执行顺序

我们手写的 SQL 顺序:

MySQL 实际执行 SQL 顺序

mysql 执行的顺序：随着 Mysql 版本的更新换代， 其优化器也在不断的升级， 优化器会分析不同执行顺序产生的性能消耗不同而动态调整执行顺序。
下面是经常出现的查询顺序：

• 总结：mysql 从 FROM 开始执行

2.2、JOIN 连接查询

join查询图

2.3 七种join语句

３ 索引

3.1 索引是什么

• MySQL官方对索引的定义为：索引(Index)是帮助MySQL高效获取数据的数据结构。可以得到索引的本质：索引是数据结构。
• 你可以简单理解为"排好序的快速查找数据结构"，即索引 = 排序 + 查找
• 一般来说索引本身占用内存空间也很大，不可能全部存储在内存中，因此索引往往以文件形式存储在硬盘上。
• 我们平时所说的索引，如果没有特别指明，都是指B树(多路搜索树，并不一定是二叉树)结构组织的索引。
• 聚集索引，次要索引，覆盖索引，复合索引，前缀索引，唯一索引默认都是使用B+树索引，统称索引。当然，除了B+树这种类型的索引之外，还有哈希索引(hash index)等。
• 索引的目的在于提高查询效率，可以类比字典。
• 在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向数据），这样就可以在这些数据结构的基础上实现高级查找算法，这种数据结构就是索引。
• update 更新慢，不仅要改数据，还要改索引，所以经常更新的数据不适合建索引。

3.2 索引的优劣势

索引的优势

• 类似大学图书馆的书目索引，提高数据检索效率，降低数据库的IO成本
• 通过索引列对数据进行排序，降低数据排序成本，降低了CPU的消耗

索引的劣势

• 实际上索引也是一张表，该表保存了主键和索引字段，并指向实体表的记录，所以索引列也是要占用空间的。
• 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如果对表INSERT，UPDATE和DELETE。因为更新表时，MySQL不仅要不存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息
• 索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句

3.3 索引分类

• 单值索引：是最基本的索引，它没有任何限制，即一个索引只包含单个列，一个表可以有多个单列索引；建议一张表索引不要超过5个，优先考虑复合索引
• 唯一索引：与前面的单值索引类似，不同的就是：索引列的值必须唯一，但允许有空值。
• 主键索引：是一种特殊的唯一索引，一个表只能有一个主键，不允许有空值。一般是在建表的时候同时创建主键索引：
• 复合索引：一个索引包含多个列

3.4、MySQL 索引语法

建立索引的 SQL 语句

创建索引：

• 如果是CHAR和VARCHAR类型，length可以小于字段实际长度；

• 如果是BLOB和TEXT类型，必须指定length

  CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));
  ’ or ’
  ALTER mytable ADD [UNIQUE] INDEX [indexName] ON(columnname(length));

删除索引
DROP INDEX [indexName] ON mytable;

查看索引（\G表示将查询到的横向表格纵向输出，方便阅读）
SHOW INDEX FROM table_name\G

使用 ALTER 命令，有四种方式来添加数据表的索引：

ALTER TABLE tbl_name ADD PRIMARY KEY(column_list)：该语句添加一个主键，这意味着索引值必须是唯一的，且不能为NULL。
ALTER TABLE tbl_name ADD UNIQUE index_name(column_list)：这条语句创建索引的值必须是唯一的（除了NULL外，NULL可能会出现多次）。
ALTER TABLE tbl_name ADD INDEX index_name(column_list)：.添加普通索引，索引值可出现多次。
ALTER TABLE tbl_name ADD FULLTEXT index_name(column_list)：该语句指定了索引为FULLTEXT，用于全文索引。

3.５、MySQL 索引结构

3.5.1、Btree 索引

Btree 索引搜索过程

【初始化介绍】

1. 一颗 b 树， 浅蓝色的块我们称之为一个磁盘块， 可以看到每个磁盘块包含几个数据项（深蓝色所示） 和指针（黄色所示）.
2. 如磁盘块 1包含数据项 17 和 35， 包含指针 P1、 P2、 P3
3. P1 表示小于 17 的磁盘块， P2 表示在 17 和 35之间的磁盘块， P3 表示大于 35 的磁盘块
4. 真实的数据存在于叶子节点和非叶子节点中

【查找过程】

1. 如果要查找数据项 29， 那么首先会把磁盘块 1 由磁盘加载到内存， 此时发生一次 IO， 在内存中用二分查找确定 29在17和35 之间， 锁定磁盘块 1 的 P2 指针， 内存时间因为非常短（相比磁盘的 IO） 可以忽略不计
2. 通过磁盘块 1的 P2 指针的磁盘地址把磁盘块 3 由磁盘加载到内存， 发生第二次 IO， 29 在 26 和 30 之间， 锁定磁盘块 3 的 P2 指针
3. 通过指针加载磁盘块 8 到内存， 发生第三次 IO， 同时内存中做二分查找找到 29， 结束查询， 总计三次 IO。

3.5.2、B+tree 索引

【B+Tree 与 BTree 的区别】

• B-树的关键字（数据项）和记录是放在一起的； B+树的非叶子节点中只有关键字和指向下一个节点的索引， 记录只放在叶子节点中。

【B+Tree 与 BTree 的查找过程】

• 在 B 树中， 越靠近根节点的记录查找时间越快， 只要找到关键字即可确定记录的存在； 而 B+ 树中每个记录的查找时间基本是一样的， 都需要从根节点走到叶子节点， 而且在叶子节点中还要再比较关键字。
• 从这个角度看 B 树的性能好像要比 B+ 树好， 而在实际应用中却是 B+ 树的性能要好些。 因为 B+ 树的非叶子节点不存放实际的数据，这样每个节点可容纳的元素个数比 B 树多， 树高比 B 树小， 这样带来的好处是减少磁盘访问次数。
• 尽管 B+ 树找到一个记录所需的比较次数要比 B 树多， 但是一次磁盘访问的时间相当于成百上千次内存比较的时间， 因此实际中B+ 树的性能可能还会好些， 而且 B+树的叶子节点使用指针连接在一起， 方便顺序遍历（范围搜索）， 这也是很多数据库和文件系统使用 B+树的缘故。

【性能提升】

真实的情况是， 3 层的 B+ 树可以表示上百万的数据， 如果上百万的数据查找只需要三次 IO， 性能提高将是巨大的，如果没有索引， 每个数据项都要发生一次 IO， 那么总共需要百万次的 IO， 显然成本非常非常高。

【思考： 为什么说 B+树比 B-树更适合实际应用中操作系统的文件索引和数据库索引？】

• B+树的磁盘读写代价更低：B+树的内部结点并没有指向关键字具体信息的指针。 因此其内部结点相对 B 树更小。 如果把所有同一内部结点的关键字存放在同一盘块中， 那么盘块所能容纳的关键字数量也越多。 一次性读入内存中的需要查找的关键字也就越多。 相对来说 IO 读写次数也就降低了。
• B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点， 而只是叶子结点中关键字的索引。 所以任何关键字的查找必须走一条从根结点到叶子结点的路。 所有关键字查询的路径长度相同， 导致每一个数据的查询效率相当。

3.6、何时需要建索引

哪些情况下适合建立索引

• 主键自动建立唯一索引
• 频繁作为查询的条件的字段应该创建索引
• 查询中与其他表关联的字段，外键关系建立索引
• 频繁更新的字段不适合创建索引
• Where 条件里用不到的字段不创建索引
• 单间/组合索引的选择问题，Who？（在高并发下倾向创建组合索引）
• 查询中排序的字段，排序字段若通过索引去访问将大大提高排序的速度
• 查询中统计或者分组字段

哪些情况不要创建索引

• 表记录太少
• 经常增删改的表
• 数据重复且分布平均的表字段，因此应该只为经常查询和经常排序的数据列建立索引。注意，如果某个数据列包含许多重复的内容，为它建立索引就没有太大的实际效果。
  

3.7 性能分析

3.7.1、性能优化概述

MySQL Query Optimizer 的作用

1. MySQL中有专门负责优化SELECT语句的优化器模块，主要功能：通过计算分析系统中收集到的统计信息，为客户端请求的Query提供它认为最优的执行计划（MySQL认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间）
2. 当客户端向MySQL 请求一条Query，命令解析器模块完成请求分类，区别出是SELECT并转发给MySQL Query Optimizer时，MySQL Query Optimizer首先会对整条Query进行优化，处理掉一些常量表达式的预算，直接换算成常量值。并对Query中的查询条件进行简化和转换，如去掉一些无用或显而易见的条件、结构调整等。然后分析Query中的Hint信息（如果有），看显示Hint信息是否可以完全确定该Query的执行计划。如果没有Hint 或Hint信息还不足以完全确定执行计划，则会读取所涉及对象的统计信息，根据Query进行些相应的计算分析，然后再得出最后的执行计划。
3. Hint是Oracle数据库中很有特色的一个功能，是很多DBA优化中经常采用的一个手段。那为什么Oracle会考虑引入优化器呢？基于代价的优化器是很聪明的，在绝大多数情况下它会选择正确的优化器，减轻DBA的负担。但有时它也聪明反被聪明误，选择了很差的执行计划，使某个语句的执行变得奇慢无比。此时就需要DBA进行人为的干预，告诉优化器使用指定的存取路径或连接类型生成执行计划，从而使语句高效地运行。Hint就是Oracle提供的一种机制，用来告诉优化器按照告诉它的方式生成执行计划。

MySQL 常见瓶颈

• CPU 瓶颈：CPU在饱和的时候一般发生在数据装入在内存或从磁盘上读取数据时候
• IO 瓶颈：磁盘I/O瓶颈发生在装入数据远大于内存容量时
• 服务器硬件的性能瓶颈：top、free、iostat和vmstat来查看系统的性能状态

3.8 Explain概述

是什么？Explain 是查看执行计划

1. 使用EXPLAIN关键字可以模拟优化器执行SQL语句，从而知道MySQL是如何处理你的SQL语句的。分析你的查询语句或是结构的性能瓶颈

   官网地址：https://dev.mysql.com/doc/refman/8.0/en/explain-output.html

能干嘛？

• 表的读取顺序（id 字段）
• 数据读取操作的操作类型（select_type 字段）
• 哪些索引可以使用（possible_keys 字段）
• 哪些索引被实际使用（keys 字段）
• 表之间的引用（ref 字段）
• 每张表有多少行被优化器查询（rows 字段）
  

怎么玩？

Explain + SQL语句
explain select * from tbl_emp;

3.9、Explain 详解

id：select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序

id 取值的三种情况：

• id相同，执行顺序由上至下
  
• id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行

• id相同不同，同时存在：id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行；衍生=DERIVED
  

select_type：查询的类型，主要用于区别普通查询、联合查询、子查询等复杂查询

• SIMPLE：简单的select查询，查询中不包含子查询或者UNION
• PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记为PRIMARY(查询中最外层的SELECT（如两表做UNION或者存在子查询的外层的表操作为PRIMARY，内层的操作为UNION)
• SUBQUERY：在SELECT或者WHERE列表中包含了子查询
• DERIVED：在FROM列表中包含的子查询被标记为DERIVED（衍生）MySQL会递归执行这些子查询，把结果放在临时表里
• UNION：若第二个SELECT出现在UNION之后，则被标记为UNION；若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED
• UNION RESULT：从UNION表获取结果的SELECT

UNION 和 UNION RESULT举例:

table：显示这一行的数据是关于哪张表的

type：访问类型排列，显示查询使用了何种类型

• type显示的是访问类型，是较为重要的一个指标，结果值从最好到最坏依次是：system>const>eq_ref>ref>fultext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>ALL
• 挑重要的来说：system>const>eq_ref>ref>range>index>ALL，一般来说，得保证查询至少达到range级别，最好能达到ref。

从最好到最差依次是：system>const>eq_ref>ref>range>index>ALL

1. system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，这个也可以忽略不计
2. const：表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。如将主键置于where列表中，MySQL就能将该查询转换为一个常量
   
3. eq_ref：唯一性索引，对于每个索引键，表中只有一条记录与之匹配，常见于主键或唯一索引扫描
   mysql中的const和ref_eq的区别
4. ref：非唯一索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以他应该属于查找和扫描的混合体。
   
5. range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引。一般就是在你的where语句中出现了between、<、>、in等的查询这种范围扫描索引扫描比全表扫描要好，因为他只需要开始索引的某一点，而结束于另一点，不用扫描全部索引。

６. index：Full Index　Scan，index与ALL区别为index类型只遍历索引树。这通常比ALL快，因为索引文件通常比数据文件小。（也就是说虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘数据库文件中读的）

７. all：FullTable Scan，将遍历全表以找到匹配的行（全表扫描）

８. 备注：一般来说，得保证查询只是达到range级别，最好达到ref

possible_keys

• 显示可能应用在这张表中的索引，一个或多个
• 若查询涉及的字段上存在索引，则该索引将被列出，但不一定被查询实际使用

key

• 实际使用的索引，如果为null，则没有使用索引

• 若查询中使用了覆盖索引，则该索引仅出现在key列表中

  覆盖索引：select语句后查询的字段和建的索引个数，顺序刚好吻合
  覆盖索引
  

  key_len

• 表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度。在不损失精确性的情况下，长度越短越好

• key_len显示的值为索引最大可能长度，并非实际使用长度，即key_len是根据表定义计算而得，不是通过表内检索出的
  

ref

• 显示索引哪一列被使用了，如果可能的话，最好是一个常数。哪些列或常量被用于查找索引列上的值
• 由key_len可知t1表的索引idx_col1_col2被充分使用，t1表的col1匹配t2表的col1，t1表的col2匹配了一个常量，即’ac’
  

rows

• 根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数

Extra：包含不适合在其他列中显示但十分重要的额外信息

１，Using filesort（文件排序）：

• MySQL中无法利用索引完成排序操作称为“文件排序”

• 说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取

• 出现 Using filesort 不好（九死一生），需要尽快优化 SQL

• 示例中第一个查询只使用了 col1 和 col3，原有索引派不上用场，所以进行了外部文件排序

• 示例中第二个查询使用了 col1、col2 和 col3，原有索引派上用场，无需进行文件排序

  

２，Using temporary（创建临时表）：

• 使用了临时表保存中间结果，MySQL在对查询结果排序时使用临时表。常见于排序 order by 和分组查询 group by

• 出现 Using temporary 超级不好（十死无生），需要立即优化 SQL

• 示例中第一个查询只使用了 col1，原有索引派不上用场，所以创建了临时表进行分组

• 示例中第二个查询使用了 col1、col2，原有索引派上用场，无需创建临时表

• 临时表的创建很伤的

  

３，Using index（覆盖索引）：

• 表示相应的select操作中使用了覆盖索引（Coveing Index），避免访问了表的数据行，效率不错！

• 如果同时出现using where，表明索引被用来执行索引键值的查找

• 如果没有同时出现using where，表明索引用来读取数据而非执行查找动作

  ![在这里插入图片描述](https://img-blog.csdnimg.cn/20201205100956892.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzZXJ0Z2gxMjM=,size_16,color_FFFFFF,t_70)
  

• 覆盖索引（Covering Index），也说为索引覆盖

1. 理解方式一：就是select的数据列只用从索引中就能够取得，不必读取数据行，MySQL可以利用索引返回select列表中的字段，而不必根据索引再次读取数据文件，换句话说查询列要被所建的索引覆盖。
2. 理解方式二：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了（或覆盖了）满足查询结果的数据就叫做覆盖索引。
3. 注意：如果要使用覆盖索引，一定要注意select列表中只取出需要的列，不可select * ，因为如果将所有字段一起做索引会导致索引文件过大，查询性能下降。

４，Using where：表明使用了where过滤
５，Using join buffer：表明使用了连接缓存，
６，impossible where：where子句的值总是false，不能用来获取任何元组

７，select tables optimized away：在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。
８，distinct：优化distinct，在找到第一匹配的元组后即停止找同样值的工作

Explain 热身 Case

1. 第一行（执行顺序4）：id列为1，表示是union里的第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中derived3中3代表该查询衍生自第三个select查询，即id为3的select。【select d1.name …】
2. 第二行（执行顺序2）：id为3，是整个查询中第三个select的一部分。因查询包含在from中，所以为derived。【select id, name from t1 where other_column= ’ '】
3. 第三行（执行顺序3）：select列表中的子查询select_type为subquery，为整个查询中的第二个select。【select id from t3】
4. 第四行（执行顺序1）：select_type为union，说明第四个select是union里的第二个select，最先执行【select name, id from t2】
5. 第五行（执行顺序5）：代表从union的临时表中读取行的阶段，table列的表示用第一个和第四个select的结果进行union操作。【两个结果进行union操作】

3.9 索引优化

3.9.1　单表索引优化分析

分析：

• 但是我们已经建立了索引，为啥没用呢？
• 这是因为按照B+Tree索引的工作原理，先排序 category_id，如果遇到相同的 category_id 则再排序comments，如果遇到相同的 comments 则再排序 views。当comments字段在联合索引里处于中间位置时，因为comments>1条件是一个范围值（所谓 range），MySQL 无法利用索引再对后面的views部分进行检索，即 range 类型查询字段后面的索引无效。
• 将查询条件中的 comments > 1 改为 comments = 1 ，发现 Use filesort 神奇地消失了，从这点可以验证：范围后的索引会导致索引失效。

3.9.2 两表索引优化

两表索引优化分析：主外键
分析：

• 这是由左连接特性决定的。LEFT JOIN条件用于确定如何从右表搜索行，左边一定都有，所以右边是我们的关键点，一定需要建立索引。
• 左表连接右表，则需要拿着左表的数据去右表里面查，索引需要在右表中建立索引

分析：

• 这是因为RIGHT JOIN条件用于确定如何从左表搜索行，右边一定都有，所以左边是我们的关键点，一定需要建立索引。
• class RIGHT JOIN book ：book 里面的数据一定存在于结果集中，我们需要拿着 book 表中的数据，去 class 表中搜索，所以索引需要建立在 class 表中

3.9.3 三表索引优化

3.9.4 结论

Join 语句优化的结论
将 left join 看作是两层嵌套 for 循环

• 尽可能减少Join语句中的NestedLoop的循环总次数； 永远用小结果集驱动大的结果集（在大结果集中建立索引，在小结果集中遍历全表）；
• 优先优化NestedLoop的内层循环；
• 保证Join语句中被驱动表上Join条件字段已经被索引；
• 当无法保证被驱动表的Join条件字段被索引且内存资源充足的前提下，不要太吝惜JoinBuffer的设置；

3.10 索引失效

索引失效（应该避免）

３.10.1、索引失效准则

索引失效判断准则

1. 全值匹配我最爱
2. 最佳左前缀法则：如果索引了多例，要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。（最佳左匹配法则：带头大哥不能死，中间兄弟不能断）
3. 不在索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描
4. 存储引擎不能使用索引中范围条件右边的列（范围之后全失效）
5. 尽量使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减少select *
6. mysql在使用不等于（!=或者<>）的时候无法使用索引会导致全表扫描
7. is null，is not null 也无法使用索引（早期版本不能走索引，后续版本应该优化过，可以走索引）
8. like以通配符开头（’%abc…’）mysql索引失效会变成全表扫描操作，一般把%写到like右边索引不会失效，eg,　like ‘July%’
9. 字符串不加单引号索引失效（如果字符串忘记写 ‘’ ，那么 mysql 会为我们进行隐式的类型转换，但凡进行了类型转换，索引都会失效）
10. 少用or，用它连接时会索引失效（注意是少用，不是不用）

解决【like ‘%str%’ 】索引失效的问题：覆盖索引
　　只要查询的字段能和覆盖索引扯得上关系，并且没有多余字段，覆盖索引就不会失效。

【优化总结口诀】
全值匹配我最爱，最左前缀要遵守；
带头大哥不能死，中间兄弟不能断；
索引列上少计算，范围之后全失效；
Like百分写最右，覆盖索引不写星；
不等空值还有or，索引失效要少用；
VAR引号不可丢，SQL高级也不难！

小总结

3.10 索引优化面试题

• EXPLAIN SELECT * FROM test03 WHERE c1=‘a1’ AND c5=‘a5’ ORDER BY c2, c3;
• EXPLAIN SELECT * FROM test03 WHERE c1=‘a1’ AND c5=‘a5’ ORDER BY c3, c2;（出现了filesort，我们建的索引是1234，它没有按照顺序来，32颠倒了）
• group by 表面上叫分组，分组之前必排序，group by 和 order by 在索引上的问题基本是一样的

*group by 语句报错解决方法*

3.11 总结

一般性建议

• 对于单键索引，尽量选择针对当前query过滤性更好的索引
• 在选择组合索引的时候，当前query中过滤性最好的字段在索引字段顺序中，位置越靠左越好。
• 在选择组合索引的时候，尽量选择可以能包含当前query中的where子句中更多字段的索引
• 尽可能通过分析统计信息和调整query的写法来达到选择合适索引的目的

索引优化的总结
-like 后面以常量开头，比如 like ‘kk%’ 和 like ‘k%kk%’ ，可以理解为就是常量

索引优化总结的口诀

全值匹配我最爱， 最左前缀要遵守；

带头大哥不能死， 中间兄弟不能断；

索引列上少计算， 范围之后全失效；

LIKE 百分写最右， 覆盖索引不写 *；

不等空值还有 OR， 索引影响要注意；

VAR 引号不可丢， SQL 优化有诀窍。