• 索引——MySQL


    索引概述

    索引:是帮助MySQL高效获取数据的数据结构(有序)。在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据, 这样就可以在这些数据结构上实现高级查找算法,这种数据结构就是索引

    假如我们要执行的SQL语句为 : select * from user where age = 45;

    在这里插入图片描述

    1. 无索引情况
      在无索引情况下,就需要从第一行开始扫描,一直扫描到最后一行,我们称之为 全表扫描,性能很低
    2. 有索引的情况下
      在这里插入图片描述只需要扫描三次就可以找到数据了,极大的提高的查询的效率。

    优缺点

    在这里插入图片描述


    索引结构

    MySQL的索引是在存储引擎层实现的,不同的存储引擎有不同的索引结构,主要包含以下几种:
    在这里插入图片描述

    1.Btree索引

    插入元素排序后如果超出,中间元素上相分裂,形成树

    B-Tree,B树是一种多叉路衡查找树,相对于二叉树,B树每个节点可以有多个分支,即多叉。
    以一颗最大度数(max-degree)为5(5阶)的b-tree为例,那这个B树每个节点最多存储4个key,对应5
    个指针

    在这里插入图片描述

    特点:

    • 5阶的B树,每一个节点最多存储4个key,对应5个指针。
    • 一旦节点存储的key数量到达5,就会裂变,中间元素向上分裂
    • 在B树中,非叶子节点和叶子节点都会存放数据。

    2. B+tree索引

    所有节点都会出现在叶子结点中,并是中间元素向上分裂

    在这里插入图片描述

    • 绿色框框起来的部分,是索引部分,仅仅起到索引数据的作用,不存储数据。
    • 红色框框起来的部分,是数据存储部分,在其叶子节点中要存储具体的数据。

    在这里插入图片描述
    B+Tree 与 B-Tree相比,主要有以下三点区别:

    • 所有的数据都会出现在叶子节点。
    • 叶子节点形成一个单向链表。
    • 非叶子节点仅仅起到索引数据作用,具体的数据都是在叶子节点存放的。

    3. hash索引

    哈希索引就是采用一定的hash算法,将键值换算成新的hash值,映射到对应的槽位上,然后存储在hash表中。

    在这里插入图片描述
    特点

    1. Hash索引只能用于对等比较(=,in),不支持范围查询(between,>,< ,…)
    2. 无法利用索引完成排序操作
    3. 查询效率高,通常(不存在hash冲突的情况)只需要一次检索就可以了,效率通常要高于B+tree索引

    存储引擎支持
    在MySQL中,支持hash索引的是Memory存储引擎。 而InnoDB中具有自适应hash功能,hash索引是
    InnoDB存储引擎根据B+Tree索引在指定条件下自动构建的。

    思考题: 为什么InnoDB存储引擎选择使用B+tree索引结构?

    1. 相对于二叉树,层级更少,搜索效率高;
    2. 对于B-tree,无论是叶子节点还是非叶子节点,都会保存数据,这样导致一页中存储的键值减少,指针跟着减少,要同样保存大量数据,只能增加树的高度,导致性能降低;
    3. 相对Hash索引,B+tree支持范围匹配及排序操作;

    索引分类

    在这里插入图片描述
    InnoDB存储引擎中,根据索引的存储形式,又可以分为以下两种:
    在这里插入图片描述
    聚集索引选取规则:

    • 如果存在主键,主键索引就是聚集索引
    • 如果不存在主键,将使用第一个唯一(UNIQUE)索引作为聚集索引。
    • 如果表没有主键,或没有合适的唯一索引,则InnoDB会自动生成一个rowid作为隐藏的聚集索引

    在这里插入图片描述

    • 聚集索引的叶子节点下挂的是这一行的数据 。
    • 二级索引的叶子节点下挂的是该字段值对应的主键值

    思考题:
    以下两条SQL语句,那个执行效率高? 为什么?
    A. select * from user where id = 10 ;
    B. select * from user where name = ‘Arm’ ;
    备注: id为主键,name字段创建的有索引;
    解答:
    A 语句的执行性能要高于B 语句。
    因为A语句直接走聚集索引,直接返回数据。 而B语句需要先查询name字段的二级索引,然后再查询聚集索引,也就是需要进行回表查询。


    索引创建语法

    1. 创建索引

    关键字:create index

    create [unique\fulltext] index 索引名 on 表名 (字段名1,字段名2) ;
    // 表示要给表中的字段名1,创建索引
    
    • 1
    • 2
    • unique:创建的是唯一索引
    • fulltext:表示创建的是全文索引
    • 不加两个可选项表示创建的是常规索引
    1. 查看索引
    show index from table_name ;
    
    • 1

    查看指定表中的所有索引

    1. 删除索引
    drop index index_name on 表名 ;
    
    • 1

    SQL性能优化

    SQL性能分析

    想要进行性能优化首先要知道,那些命令的执行效率低,就需要性能分析

    MySQL 客户端连接成功后,通过 show [session|global] status 命令可以提供服务器状态信
    息。

    • global:全局的状态信息
    • session:查看当前对话的状态信息

    通过如下指令,可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次:

    show global status like 'Com_______'; # 7个下划线
    
    • 1

    在这里插入图片描述
    value值就是这个数据库以往执行各种命令的次数,可以根据各种命令的执行次数,做出相关的优化

    慢查询日志

    慢查询日志记录了所有执行时间超过指定参数(long_query_time,单位:秒,默认10秒)的所有SQL语句的日志。

    MySQL的慢查询日志默认关闭,我们可以查看一下系统变量 slow_query_log。

    查看慢查询日志的状态
    show  variables like 'slow_query_log' ;
    
    • 1
    • 2

    在这里插入图片描述

    开启慢查询日志

    需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息

    # 开启MySQL慢日志查询开关
    slow_query_log=1
    # 设置慢日志的时间为2秒,SQL语句执行时间超过2秒,就会视为慢查询,记录慢查询日志
    long_query_time=2
    
    • 1
    • 2
    • 3
    • 4

    设置之后需要重启MySQL数据库

    profile(查看耗时的去处)

    开启profile

    show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了。
    通过have_profiling参数,能够看到当前MySQL是否支持profile操作:

    1. 查看当前MySQL是否支持profile操作
    查看当前MySQL是否支持profile操作
    select @@have_profiling ;
    
    • 1
    • 2

    在这里插入图片描述

    1. 查看profile是否开启
    select @@profiling ;
    
    • 1

    在这里插入图片描述

    1. 开启profile
    set profiling = 1 ;
    
    • 1

    查看所有指令的耗时情况

    当我们执行了很多select语句之后,想要知道这些select语句的执行指令之后,就可以通过show profiles指令查看刚刚所有执行过的select语句的执行情况

    语法:show profiles ;
    查询制定项:show profile for query 所查项 ;

    -- 查看每一条SQL的耗时基本情况
    show profiles;
    
    
    -- 查看指定的SQL语句各个阶段的耗时情况
    show profile for query query_id;
    
    
    -- 查看指定query_id的SQL语句CPU的使用情况
    show profile cpu for query query_id;
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    explain(执行计划)

    前几种方法只是通过时间的长短来判别SQL的性能,不能真正反映SQL的性能
    通过explain查看一天SQL语句的执行计划

    语法:直接在select语句之前加上关键字 explain / desc,就可以查询当前语句的执行计划

    explain select 字段列表 from 表名 where 条件 ;
    
    • 1

    会查询出很多列
    在这里插入图片描述

    字段含义
    idselect查询的序列号,表示查询中执行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表示索引中使用的字节数, 该值为索引字段最大可能长度,并非实际使用长度,在不损失精确性的前提下,长度越短越好。
    rowsMySQL认为必须要执行查询的行数,在innodb引擎的表中,是一个估计值,可能并不总是准确的。
    filtered表示返回结果的行数占需读取行数的百分比, filtered 的值越大越好。

    索引的使用

    索引的原则

    最左前缀法则

    如果索引了多列(联合索引),要遵守最左前缀法则。最左前缀法则指的是查询从索引的最左列开始,并且不跳过索引中的列。如果跳跃某一列,索引将会部分失效(后面的字段索引失效)。

    最左边的列必须存在,在select中的位置无所谓

    在 tb_user 表中,有一个联合索引,这个联合索引涉及到三个字段,顺序分别为:profession,age,status。对于最左前缀法则指的是,查询时,最左变的列,也就是profession必须存在,否则索引全部失效。而且中间不能跳过某一列,否则该列后面的字段索引将失效。
    只要最左边的字段存在就可以,不需要考虑顺序问题

    范围查询(>或<右侧的索引会失效)

    联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效。
    explain select * from tb_user where profession = '软件工程' and age > 30 and status= '0';
    在这里插入图片描述

    当范围查询使用> 或 < 时,走联合索引了,但是索引的长度为49,就说明范围查询右边的status字段是没有走索引的。
    explain select * from tb_user where profession = '软件工程' and age >= 30 andstatus = '0';
    在这里插入图片描述

    当范围查询使用>= 或 <= 时,走联合索引了,但是索引的长度为54,就说明所有的字段都是走索引的。

    所以,在业务允许的情况下,尽可能的使用类似于 >= 或 <= 这类的范围查询,而避免使用 > 或 <

    索引失效情况

    索引列中有运算操作会失效

    不要在索引列上进行运算操作, 索引将失效。

    在tb_user表中,除了前面介绍的联合索引之外,还有一个索引,是phone字段的单列索引
    A. 当根据phone字段进行等值匹配查询时, 索引生效。
    explain select * from tb_user where phone = '17799990015';
    在这里插入图片描述

    B. 当根据phone字段进行函数运算操作之后,索引失效。
    explain select * from tb_user where substring(phone,10,2) = '15';
    在这里插入图片描述

    字符串不加引号会失效

    字符串类型字段使用时,不加引号,索引将失效。
    接下来,我们通过两组示例,来看看对于字符串类型的字段,加单引号与不加单引号的区别:
    explain select * from tb_user where profession = '软件工程' and age = 31 and status = '0';
    explain select * from tb_user where profession = '软件工程' and age = 31 and status = 0;

    在这里插入图片描述我们会明显的发现,如果字符串不加单引号,对于查询结果,没什么影响,但是数据库存在隐式类型转换,索引将失效。

    模糊查询出现在头部会失效

    如果仅仅是尾部模糊匹配,索引不会失效。如果是头部模糊匹配,索引失效。

    我们主要看一下,模糊查询时,%加在关键字之前,和加在关键字之后的影响。

    explain select * from tb_user where profession like '软件%'; 有效
    explain select * from tb_user where profession like '%工程'; 失效
    explain select * from tb_user where profession like '%工%'; 失效

    在这里插入图片描述

    在like模糊查询中,在关键字后面加%,索引可以生效。而如果在关键字
    前面加了%,索引将会失效。

    or连接条件左右两侧字段都有索引索引才生效

    用or分割开的条件, 如果or前的条件中的列有索引,而后面的列中没有索引,那么涉及的索引都不会被用到。

    由于age没有索引,所以即使id、phone有索引,索引也会失效。所以需要针对于age也要建立索引。

    然后,我们可以对age字段建立索引。
    建立了索引之后,我们再次执行上述的SQL语句,看看前后执行计划的变化。

    explain select * from tb_user where id = 10 or age = 23;
    explain select * from tb_user where phone = '17799990017' or age = 23
    
    • 1
    • 2

    在这里插入图片描述

    由于age没有索引,所以即使id、phone有索引,索引也会失效。所以需要针对于age也要建立索引。
    当or连接的条件,左右两侧字段都有索引时,索引才会生效。

    数据分布影响

    如果MySQL评估使用索引比全表更慢,则不使用索引。

    select * from tb_user where phone >= '17799990005';
    select * from tb_user where phone >= '17799990015';
    
    • 1
    • 2

    在这里插入图片描述

    经过测试我们发现,相同的SQL语句,只是传入的字段值不同,最终的执行计划也完全不一样,这是为什么呢?
    就是因为MySQL在查询时,会评估使用索引的效率与走全表扫描的效率,如果走全表扫描更快,则放弃索引,走全表扫描。 因为索引是用来索引少量数据的,如果通过索引查询返回大批量的数据,则还不如走全表扫描来的快,此时索引就会失效。

    接下来,我们再来看看 is null 与 is not null 操作是否走索引。
    执行如下两条语句 :

    explain select * from tb_user where profession is null;
    explain select * from tb_user where profession is not null;
    
    • 1
    • 2

    在这里插入图片描述

    profession 的 null值数量会影响在查询profession中的null值是否走索引还是全表扫描

    查询时MySQL会评估,走索引快,还是全表扫描快,如果全表扫描更快,则放弃索引走全表扫描。 因此,is null 、is not null是否走索引,得具体情况具体分析,并不是固定的。

    SQL提示

    SQL提示,是优化数据库的一个重要手段,简单来说,就是在SQL语句中加入一些人为的提示来达到优
    化操作的目的。

    1. use index : 建议MySQL使用哪一个索引完成此次查询(仅仅是建议,mysql内部还会再次进行评估)。
    explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';
    
    • 1
    1. ignore index : 忽略指定的索引。
    explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';
    
    • 1
    1. force index : 强制使用索引。
    explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';
    
    • 1

    覆盖索引

    尽量使用覆盖索引,减少select *。 那么什么是覆盖索引呢?
    覆盖索引是指 查询使用了索引,并且需要返回的列,在该索引中已经全部能够找到 。

    前缀索引

    当字段类型为字符串(varchar,text,longtext等)时,有时候需要索引很长的字符串,这会让索引变得很大,查询时,浪费大量的磁盘IO, 影响查询效率。此时可以只将字符串的一部分前缀,建立索引,这样可以大大节约索引空间,从而提高索引效率。

    1. 语法:
    create index 前缀索引名 on 表名(字段名(n)) ;
    
    • 1

    为tb_user表的email字段,建立长度为5的前缀索引。

    create index idx_email_5 on tb_user(email(5));
    
    • 1

    在这里插入图片描述

    1. 前缀长度
      可以根据索引的选择性来决定,而选择性是指不重复的索引值(基数)和数据表的记录总数的比值,索引选择性越高则查询效率越高, 唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的。
    select count(distinct email) / count(*) from tb_user ;
    select count(distinct substring(email,1,5)) / count(*) from tb_user ;
    
    • 1
    • 2
    1. 前缀索引的查询流程

    在这里插入图片描述

  • 相关阅读:
    VsCode中设置文本格式化(超详细)
    使用AOP切面实现日志记录功能
    STM32CubeIDE设置Flash烧录地址和大小(告别Keil魔术棒)
    网络模块使用Hilt注入
    莱特兄弟的家庭教育
    驱动加载module license ‘unspecified‘ taints kernel问题
    [尚硅谷React笔记]——第1章 React简介
    sdkman 的安装配置与 sdk 管理
    异地多活架构的3种模式
    在el-table表头上引入组件不能实时传参bug
  • 原文地址:https://blog.csdn.net/mankeywang/article/details/123698853