MySql高级(上)之索引优化分析和EXPLAIN关键字

1、MySql的逻辑架构简介

1、1 整体架构图

在这里插入图片描述
和其他数据库相比,MySQL有点与众不同,它的架构可以在多种不同的场景中应用并发挥良好的作用。主要体现在存储引擎的架构上,插件式的存储引擎架构将查询处理和其他的系统任务以及数据的存储提取分离,这种架构可以根据业务的需求和实际需要选择合适的存储引擎

1、1、1 连接层

最上层是一些客户端和连接服务,包含本地sock通信和大多数基于客户端/服务端工具实现的类似于tcp/ip的通信。主要完成一些类似于连接处理、授权认证、及相关的安全方案。在该层上引入了线程池的概念,为通过认证安全接入的客户端提供线程。同样在该层上可以实现基于SSL的安全链接,服务器也会为安全接入的每个客户端验证它所具有操作权限。

1、1、2服务层

  • Management Services & Utilities :系统管理和控制工具
  • SQL Interface:sql接口,接受用户的sql命令,并且返回用户需要查询的结果,比如select from 就是调用SQL Interface
  • Oarser:解析器。SQL命令传递到解析器的时候就会被解析器验证和解析
  • Optimizer:查询优化器。SQL语句在查询之前会使用查询优化器进行优化,比如有where条件时,优化器来决定先投影还是先过滤
  • Cache 和 Buffer:查询缓存。如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取 数据。这个缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,key 缓存, 权限缓存等

1、1、3 引擎层

存储引擎层,存储引擎层真正负责了Mysql中数据的存储和提取,服务器通过API与存储引擎进行通信,不同的存储引擎具有的功能不同,这样我们可以根据自己的实际需要进行选取。

1、1、4 存储层

数据存储层,主要是将数据存储在运行于裸设备的文件系统之上,并完成于存储引擎的交互

1、2 show profile

利用show profile可以查看sql的执行周期

1、2、1 开启profile

查看profile是否开启?:show variable like’%profiling%’;
在这里插入图片描述
如果没有开启,可以执行set profiling=1开启!

1·、2、2 使用profile

执行show profiles命令,可以查看最近的几次查询
在这里插入图片描述

根据Query_ID,可以进一步执行show profile cpu,block io for query Query_id 来查看sql的具体执行步骤
在这里插入图片描述

1、2、3 大致的查询流程

mysql的查询流程大致是:
mysql客户端通过协议与mysql服务器建立连接,发送查询语句,先检查查询缓存,如果命中,直接返回结果,否则进行语句解析,也就是说,在解析查询之前,服务器会先访问查询缓存(query cache)–它存储SELECT语句以及相应的查询结果集,如果某个查询结果已经位于缓存中,服务器就不知再对查询进行解析、优化、以及执行。他仅仅将缓存中的结果返回给用户即可,这将大大提高系统的性能。
语法接洗和预处理:首先musql通过关键字将SQL语句进行解析,并生成一颗对应的"解析树"。mysql解析器将使用mysql语法规则验证和解析查询;预处理则根据一些mysql规则进一步查询解析数是否合法
查询优化器当解析树被认为是合法的了,并且由优化器将其转换成执行计划,一条查询语句可以有很多种执方式,最后都是返回i相同的结果,优化器的作用就是找到这其中最好的执行计划。
然后mysql默认使用的BTREE索引,并且一个大致方向是:无论怎么折腾sql,至少在目前来说,mysql最多用到表中的一个索引。

1、2、4 SQL的执行顺序

手写的顺序:
在这里插入图片描述
真正的执行顺序:
随着Mysql版本的更新换代,其优化器也在不断的升级,优化器会分析不同的执行顺序产生的性能消耗不同而动态执行顺序,下面是进厂出现的查询顺序:
在这里插入图片描述
在这里插入图片描述

1、2、4 MyISAM和InnoDB

在这里插入图片描述
在这里插入图片描述
show engines:查看所有的数据库引擎
在这里插入图片描述
show variables like ‘%storage_engine%’ 查看默认的数据库引擎
在这里插入图片描述

扫描二维码关注公众号,回复: 11944911 查看本文章

2、索引的优化分析

2、1 索引的概念

2、1、1 是什么?

MySQL官方对索引的定义为:索引(index)是帮助MySQL高效获取数据的数据结构。可以得到索引的本质;索引是数据结构,可以简单理解为排好序的快速查找数据结构
在数据之外,数据库系统还维护这满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据。这样就可以在这些数据结构上实现高级查找算法,这种数据结构就是索引,下图就是一种可能的索引方式示例:
在这里插入图片描述
左边是数据表,一共有七条数据,最左边是数据记录的物理地址,为了加快Gol2的查找,可以维护一个右边所示的二叉查找树,每个节点包含索引键值和一个指向对应数据记录物理地址的指针,这样就可以运用二叉查找在一定的复杂度内获取到相应的数据,从而快速的检索出符合条件的记录
一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上

2、1、2 优缺点

优点

  • 提高数据检索的效率,降低数据库的IO成本
  • 通过索引列对数据进行排序,降低数据排序的成本,降低了CPU的消耗

劣势

  • 虽然索引大大提升了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATA和DELETE,因为更新表达的时候,mysql不仅要保存数据,还要保存一下索引文件每次更新添加了索引列的字段,都会调整以内更新所带来的键值变化后的索引信息
  • 实际上索引也是一张表,该表保存了主键与所引字段,并指向实体表的记录,所以索引列也是要占用空间的。

2、2 Mysql的索引

2、2、1 Btree 索引

MySQL使用的是Btree索引
在这里插入图片描述
【初始化介绍】
一颗b树,浅蓝色的块我们称之为一个磁盘,可以看到每个磁盘块中包含几个数据项和指针(黄色所示)
如磁盘块1中包含数据项17和35 包含指针P1、P2、P3
P1这个指针指向小于17的磁盘块,P2指向大于17但是小于35的磁盘块,P3表示大于35的磁盘块
但是真实的数据只有3、5、9、10、13、15、28、29、36、68、75、79、90、99
非叶子节点不存储真实的数据,只存储指引搜索方向的数据项,如8、12 并不真实存储在数据表中。

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

2、3 B+tree索引

在这里插入图片描述
B+Tree 与B-tree的区别

  • 1)、B-树的关键字和记录是放在一起的,叶子借点可以看作外部节点,不包含任何信息;B+树的非叶子节点中只有关键字和指向下一个节点的索引,记录只放在叶子节点中。
  • 2)、在B-树种,越靠近根节点的记录查找时间越快,只要找到关键字即可额确定在记录的存在;而B+树种每个记录的查找时间基本是一样的,都需要从根节点走到叶子节点,而且在叶子节点中还要再比较关键字,从这个角度看B-树的性能好像要比B+树好,而在实际中应用的确是B+树的性能好一些,因为B+树的非叶子节点不存放实际数据,这样每个节点可容纳的元素个数就比B-树多,树高比B-树小,这样带来的好处就是减少磁盘访问次数,尽管B+树找到一个记录所需要的次数要比B-树多,但是一次磁盘访问的时间相当于成百上千次内存比较的时间,因此实际中B+树的性能可能还会好些,而且B+树的叶子节点使用指针连接在一起,方便顺序遍历(例如查看一个目录下的所有文件,一个表中的所有记录等)这也是很多数据库和文件系统使用B+树的缘故。

思考:为什么说B+树比B-树更适合实际应用总操作系统的文件索引和数据库索引?
①、B+树的内部节点并没有指向关键字具体信息的指针,因此其内部节点相对B树更小,如果把所有同一内部节点的关键字存放在同一个盘块中,那么盘块所能容纳的关键字数量也更多,一次性读入内存中的需要查找的关键字也就越多,相对来说IO读写的次数也就降低了
②、B+树的查询效率更加稳定
由于非终结点并不是最终指向文件内容的借点,而只是叶子节点中关键字的索引。所以任何关键字的查找必须走一条从根节点到叶子节点的路,所有的关键字的查询的路径长度相同,导致每个数据的查询效率相当。

2、4 聚簇索引和非聚簇索引

聚簇索引并不是一种单独的索引类型,而是一种数据源的存储方式,术语“聚簇”表示数据行和相邻的键值聚簇的存储在一起,如下图,左侧的索引就是聚簇索引,因为数据行子磁盘中的排序和索引排序保持一致
在这里插入图片描述
聚簇索引的好处:
按照聚簇索引排列顺序,查询显示一定范围数据的时候,由于数据都是紧密相连,数据库不用从多个块中提取数据,所以节省了大量的io操作
聚簇索引的限制:
对于mysql数据库目前只有innodb数据引擎支持聚簇索引,而Myisam并不支持聚簇索引。
由于物理存储排序的防止只能有一种,所以每个mysql的表只能有一个聚簇索引,一般情况下,就是该表的主键
为了充分利用聚簇索引的特性,索引innodb表的主键列尽量选用有序的顺序id,而不建议用无序的id 比如uuid这种。

2、4 时间复杂度(扩展)

同一问题可用不同算法解决,而一个算法的质量优劣将影响到算法乃至程序的效率。算法分析的目的在于选择合适算法和改进算法
时间复杂度是执行算法所需要的计算工作量,用大O表示记为:O(…)
在这里插入图片描述
在这里插入图片描述

3 Mysql的索引分类

3、1 单值索引

概念:即一个索引只包含单个列,一个表可以有多个单列索引
语法:

  • 和表一起创建:
    CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT,customer_no VARCHAR(200),customer_name VARCHAR(200),
    PRIMARY KEY (id),
    KEY(customer_name)
    );
  • 单独创单值索引
    CREATE INDEX idx_customer_name ON customer(customer_name);

唯一索引

概念:索引列的值必须唯一,但是允许有空值

  • 随表一起创建:
    CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT,customer_no VARCHAR(200),customer_name VARCHAR(200),
    PRIMARY KEY(id)
    KEY(customer_name),
    UNIQUE(customer_no)
    );
  • 单独建唯一索引
    CREATE UNIQUE INDEX idx_customer_no ON customer(customer_no);

3、3 主键索引

概念:设定为主键后数据库自动简历索引,innodb为聚簇索引

  • 随表一起建索引:
    CREATE TABLE customer (id INT(10) UNSIGNED AUTO_INCREMENT,customer_no VARCHAR(200),customer_name VARCHAR(200),
    PRIMARY KEY(id)
    );
  • 单独建主键索引:
    ALRER TABLE customer add PRIMARY KEY customer(customer_no);
  • 删除建主键索引
    ALTER TABLE customer drop PRIMARY KEY;
  • 修改建主键索引
    必须先删除掉(drop)原索引,再新建(add)索引

3、4 复合索引

概念:即一个索引包含多个列
随表一起建索引:
CREATE TABLE sustomer (id INT(10) UNSIGNED AUTO_INCREMENT,customer_no VARCHAR(200),customer_name VARCHAR(200),
PRIMARY KEY(id),
KEY(customer_name),
UNIQUE(customer_name),
KEY(customer_no,customer_name)
);
单独建索引:
CARATE INDEX idx_no_name ON customer(customer_no,customer_name);

3、5 基本语法

操作 命令
创建 CREATE [UNIQUE] INDEX[indexName] ON table_name(column)
删除 DROP INDEX[indexName] ON mytable;
查看 SHOW INDEX FROM table_name\G
使用Alter命令 ALTER TABLE tbl_name ADD PRIMARY KEY(column_list):该语句添加一个主键,这意味着索引值必须是唯一的,且不能为NULL
ALTER TABLE tbl_name ADD PRIMARY KEY (column_list)
ALTER TABLE tbl_name ADD INDEX index_name (column_list): 添加普通索引,索引值可出现多次。
ALTER TABLE tbl_name ADD FULLTEXT index_name (column_list):该语句指定了索引为 FULLTEXT ,用于全文索 引。

4、索引的创建时机

4、1 适合创建索引的情况

  • 主键自动建立唯一索引
  • 频繁作为查询条件的字段应该创建索引
  • 查询中与其他表关联的字段,外键关系建立索引
  • 单键/组合索引的字段,排序字段若通过索引去访问将大大提高排序速度
  • 查询中统计或者分组字段

4、2 不适合创建索引的情况

  • 表记录太少
  • 经常增删改的表或者字段
  • Where条件里用不到的字段不创建索引
  • 过滤性不好的不适合建索引

5、Explain 性能分析

5、1 概念:

使用EXPLAIN关键字可以模拟优化器执行SQL查询语句,从而知道MySQL是如何处理你的SQL语句的,分析你的查询语句或是表结构的性能 瓶颈。
用法:Explain+SQL语句。
Explain 执行后返回的信息。
在这里插入图片描述

5、2 Explain准备工作

CREATE TABLE t1(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t2(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id)); 
CREATE TABLE t3(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id));
CREATE TABLE t4(id INT(10) AUTO_INCREMENT,content VARCHAR(100) NULL , PRIMARY KEY (id)); 
INSERT INTO t1(content) VALUES(CONCAT('t1_',FLOOR(1+RAND()*1000))); 
INSERT INTO t2(content) VALUES(CONCAT('t2_',FLOOR(1+RAND()*1000))); 
INSERT INTO t3(content) VALUES(CONCAT('t3_',FLOOR(1+RAND()*1000))); 
INSERT INTO t4(content) VALUES(CONCAT('t4_',FLOOR(1+RAND()*1000)));

5、3 id

select查询的序列号,包含一组数字,表示查询中执行select字句或操作表的顺序。
①:id相同,执行顺序由上至下
在这里插入图片描述
② id不同,如果是子查询,id的序列号回递增,id值越大优先级越高,越先被执行。
在这里插入图片描述
③ 有相同也有不同
在这里插入图片描述
id如果相同,可以认为是一组,从上而下顺序执行,id值越大,优先级越高,越先执行。
衍生=DERIVED
关注点:id号每个号码,表示一躺独立的查询,一个sql的查询次数越少越好。

5、4 select_type

select_type 代表插叙你的类型,主要是用于区别普通查询、联合查询、子查询等复杂的查询
在这里插入图片描述

select_type属性 含义
SIMPLE 简单的select查询,查询中不包含子查询或UNION
PRIMARY 查询中若包含任何复杂的子部分,最外层查询则被标记成Primary
DERIVED 在FROM列表中包含的子查询被标记为DERIVED(衍生)Mysql会递归的执行这些子查询,把结果放在临时表中
SUBQUERY 在SELECT或WHERE列表 中包含了子查询
DEPEDENT SUBQUERY 在SELECT或WHERE列表中包含了子查询,子查询基于外层
UNCACHEABLE SUBQUERY 无法使用缓存的子查询
UNION RESULF 从UNION表获取结果的SELECT

5、4、1 SIMPLE

simple代表单表查询:
在这里插入图片描述

5、4、2 PRIMARY

查询中若包含任何复杂的子部分,最外层查询就被标记为Primary
在这里插入图片描述

5、4、3 DERIVED

在FROM列表中包含的子查询被标记为DERIVED(衍生),MySQL会递归执行这些子查询,把结果房子啊临时表里。

5、4、4 SUBQUERY

在SELECT或WHERE列表中包含了子查询
在这里插入图片描述

5、4、5 DEPENDENT SUBQUERY

在SELECTE或WHERE列表中包含了子查询,子查询基于外层
在这里插入图片描述
都是where后面的条件,subquery 是单个值,dependent subquery是一组值

5、4、6 UNCACHEABLE SUBQUERY

在这里插入图片描述
当使用@@来引用变量的时候,不会使用缓存

5、4、7 UNION

若第二个SELECT出现在UNION之后,则被标记为UBNION;若UION包含在FROM字句中的子查询中,外层SELECT将被标记为:DERIVED。
在这里插入图片描述

5、4、8 UNION RESULT

从UNION表中获取结果的SELECT。

5、5 table

这个数据是基于哪张表的

5、6 type

type 是查询的访问类型,是较为重要的一个指标,结果只从最好到最坏的依次是:
system > const > eq_ref>ref >fulltext>ref_or_null> index>merge>unique_subique>index_subquery>range>index>ALL,一般来说,得保证查询至少达到range级别,最好能达到ref。

5、6、1 system

表中只有一行记录(等于系统),这是const类型的特例,平时不会出现这个,这个也可以忽略不计。

5、6、2 const

表示通过索引一次就找到了,const用于比较parmary key 或者 unique索引,因为只匹配一行数据,所以很快如将主键置于where列表中,MySQL就能将该查询转换成一个常量。
在这里插入图片描述

5、6、3 eq_ref

唯一性索引扫描,对于每个索引键 ,表中只有一条数据与之匹配,常见于主键或唯一索引扫描。
在这里插入图片描述

5、6、4 ref

非唯一性索引扫描,返回匹配某个单独值得所有行,本质上也是一种索引访问,它返回所有匹配某个单独值得行,然而,他可能会找到多个符合条件的行,所以他应该属于查找和扫描的混合体。
没有应索引前:
在这里插入图片描述
简历索引后:
在这里插入图片描述

5、6、5 range

只检索给定范围的行,使用一个索引来选择行。key列显示使用了哪个索引,一般就是在你的where语句中出现了between、<、>、in等的查询这种范围扫描索引比全表扫描要好,因为它只需要开始于索引的某一点,而结束于另一点,不用扫描全部索引。
在这里插入图片描述
在这里插入图片描述

5、6、6 index

出现index是sql使用了索引,但是没有通过索引进行过滤,一般是使用了覆盖索引或者是利用了索引进行了排序分组。
在这里插入图片描述

5、6、7 all

FULL Table Scan 将遍历全表以找到匹配的行。
在这里插入图片描述

5、6、8 index_merge

在查询过程中需要多个索引组合使用,通常出现在有or的关键字的sql中。
在这里插入图片描述

5、6、9 ref_or_null

对于某个字段既需要关联条件,也需要null值的情况下,查询优化器会选择使用ref_or_null连接查询。
在这里插入图片描述

5、6、10 index_subquery

利用索引来关联子查询,不再全表扫描
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

5、6、11 unique_subquery

该连接烈性类似于index_subquery 子查询中的唯一索引,
在这里插入图片描述
备注:一般来说,得保证查询至少达到range级别,最好能达到ref

5、7 possible_keys

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

5、8 key

实际上使用的索引,如果是null 就代表没有使用到索引

5、9 key_len

表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度。key_len字段能够帮你检查是否充分的利用上了索引。key_len越长,说明索引使用的越充分。
在这里插入图片描述
在这里插入图片描述
如何计算:

  • 先看索引上字段的类型+长度,比如int=4,varchar(20)=10,char(20)=20;
  • 如果是varchar或char这种字符串长度,视字符串集要乘不同的值,比如utf-8,要乘3,GBK要乘2
  • varchar这种动态字符串要加2个字节
  • 允许为空的字段要加1个字节

第一组:key_len=age 的字节长度+name的字节长度=4+1+(20*3+2)=5+62=67
第二组:key_len=age的字节长度=4+1=5
在这里插入图片描述

5、10 ref

下是索引的那一列被使用了,如果可能的话,是一个常数。哪些列或者常量被用于查找索引列上的值。
在这里插入图片描述

5、11 rows

rows列显示MySQL认为它执行查询时,必须检查的行数,越少越好。
在这里插入图片描述

5、12 Extra

其他额外重要的信息

5、12、1 Using filesort

说明mysql会对数据使用一个外部的索引排序,而不是按照表内的索引顺序进行读取。Mysql中无法利用索引完成的排序操作称为“文档排序”
出现filesort的情况:
在这里插入图片描述
优化后,不再出现filesort的情况。
在这里插入图片描述
查询中排序的字段,排序字段通过索引去访问将大大提高排序的速度

5、12、2 Using temporary

使用了临时表保存中间结果,Mysql在对查询结果进行排序时,使用临时表,常见于排序,order by 和分组查询group by。
优化前:
在这里插入图片描述
优化后:
在这里插入图片描述

5、12、3 Using index

Using index 代表表示相应的select操作中使用了覆盖索引(Covering index),避免访问了表的数据行,效率不错!如果同时出现using where,表明索引被用来执行索引键值的查找;如果没有同时出现using where,表明只是用来读取数据而非利用索引执行查找。
利用索引进行了排序或分组。

5、12、4 Using where

表明使用了where过滤

5、12、5 Using join buffer

在这里插入图片描述
使用了连接缓存

5、12、6 impossible where

where字句的值总是false,不能用来获取任何元组。
在这里插入图片描述

5、12、7 select tables optimized away

在没有GROUP BY 字句的情况下,基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作,不必等到执行阶段在进行计算,查询执行计划生成的阶段即完成优化。
在inmodb中:
在这里插入图片描述
在MyISAM 中:
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/l2470334493/article/details/108581275