【MySQL-24】万字全面解析＜索引＞——【介绍＆语法＆性能分析＆使用规则】

前言

大家好吖，欢迎来到 YY 滴MySQL系列，热烈欢迎！本章主要内容面向接触过C++的老铁

主要内容含：

欢迎订阅 YY滴C++专栏！更多干货持续更新！以下是传送门！

YY的《C++》专栏

YY的《C++11》专栏

YY的《Linux》专栏

YY的《数据结构》专栏

YY的《C语言基础》专栏

YY的《单片机》专栏

YY的《STM32》专栏

YY的《数据库》专栏

一.索引概述

1.索引基本概念

索引(index)是帮助MvSOL高效获取数据的数据结构(有序)
低效获取数据：例如全表扫描等
高效获取数据：二叉树等（示意图而已，不是真实索引结构）

2.索引的优缺点

优点：

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

缺点：

索引列也是要占用空间的
索引大大提高了查询效率，同时却也降低更新表的速度，如对表进行INSERT、UPDATE、DELETE时，效率降低

二.索引结构＆分类

1.介绍＆不同索引在不同引擎中的适用情况

MySQL的索引是在存储引擎层实现的，不同的存储引擎有不同的结构，主要包含以下几种:

B+Tree索引 ：最常见的索引类型，大部分引擎都支持 B+ 树索引
Hash索引 ：底层数据结构是用哈希表实现的,只有精确匹配索引列的查询才有效,不支持范围查询
R-tree(空间索引) ：空间索引是MVISAM引擎的一个特殊索引类型，主要用于地理空间数据类型，通常使用较少
Full-text(全文索引)：是一种通过建立倒排索引,快速匹配文档的方式。类似于Lucene,Solr,ES

不同索引在不同引擎中的适用情况：

2.Btree（多路平衡查找树）

【1】为什么不用二叉树的原因

特性：比节点小排左边，比节点大排右边
缺点：顺序插入时，会形成一个链表，查询性能大大降低。大数据量情况下，层级较深
检索速度慢

【2】Btree

3.B+tree

【1】B+tree

特点：所有的元素都会出现在叶子节点，形成单向链表
机制：非叶子节点充当索引作用，即指针；叶子节点存放数据

MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的B+Tree，提高区间访问的性能。
InnoDB引擎的逻辑存储结构，表空间->段->区->页->行；页在InnoDB引擎中默认大小16k

【2】为什么InnoDB存储引擎选择使用B+tree索引结构?

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

4.hash哈希

哈希索引就是采用一定的hash算法，将键值换算成新的hash值，映射到对应的槽位上，然后存储在hash表中。
如果两个(或多个)键值，映射到一个相同的槽位上，他们就产生了hash冲突(也称为hash碰撞)，可以通过链表来解决。

Hash索引特点：

Hash索引只能用于对等比较(=，in)，不支持范围查询(between，>，<，...)
无法利用索引完成排序操作
查询效率高，通常只需要一次检索就可以了，效率通常要高于B+tree索引

存储引擎支持：

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

三.索引不同分类方式＆演示

索引常规分为4种，分别是：

主键索引 ：针对于表中主键创建的索引，默认自动创建,只能有一个，关键字PRIMARY
唯一索引 ：避免同一个表中某数据列中的值重复，可以有多个，关键字UNIQUE
常规索引：快速定位特定数据，可以有多个，无关键字
全文索引 ：全文索引查找的是文本中的关键词，而不是比较索引中的值，可以有多个，关键字FULLTEXT

在InnoDB存储引擎中，根据索引的存储形式，又可以分为以下两种：

聚集索引(Clustered Index) ：将数据存储与索引放到了一块，索引结构的叶子节点保存了行数据。必须有，而且只有一个
二级索引(SecondaryIndex) ：将数据与索引分开存储，索引结构的叶子节点关联的是对应的主键。可以存在多个

聚集索引存储规则:

如果存在主键，主键索引就是聚集索引**(聚集索引一定存在)**

如果不存在主键，将使用第一个唯一(UNIQUE)索引作为聚集索引

如果表没有主键，或没有合适的唯一索引，则InnoDB会自动生成一个rowid作为隐藏的聚集索引

聚集索引和二级索引演示：

四.索引的语法＆完成需求演示

1.索引的语法

创建索引

c 复制代码

CREATE [UNIQUE|FULLTEXT] INDEX index_name ON table_name ( index_col_name,...) ;

查看索引

c 复制代码

SHOW INDEX FROM table_name  （最后加上\G，可转换显示方式，由列展示变行展示）

删除索引

c 复制代码

DROP INDEX index_name ON table_name;

2.完成需求演示

按照下列的需求，完成索引的创建：

介绍表tb_user表：
需求
查看索引

cpp 复制代码

-- 需求1：name字段为姓名字段，该字段的值可能会重复，为该字段创建索引。
create index idx_user_name on tb_user(name);

-- 需求2：phone手机号字段的值，是非空，且唯一的，为该字段创建唯一索引。
create unique index idx_user_phone on tb_user(phone);

-- 需求3：为profession、age、status创建联合索引。
create index idx_user_pro_age_sta on th_user(profession,age,status);

-- 需求4：为email建立合适的索引来提升查询效率。
create index idx user_email on tb_user(email);

-- 删除索引
drop index idx_user_email on tb_user;

五.索引性能分析工具------>为sql优化(select)做准备

1.查看SQL执行频次

【1】为什么要关注执行频率

有张表数据量大，但是只插入不查询，所以没必要优化；
通过查看增删改/查占数据库操作的比例，来判断是否需要优化

【2】查看SQL执行频次语法＆演示

MySQL客户端连接成功后，通过show [sessionlglobal] status命令可以提供服务器状态信息。通过如下指令，可以查看当前数据库的INSERT、UPDATE、DELETE、SELECT的访问频次:

c 复制代码

SHOW GLOBAL STATUS LIKE 'Com_______'; --模糊匹配，7个_代表7个字符

我们要关注增删查改操作

2.慢查询日志

【1】慢查询日志机理机理＆作用＆语法

慢查询日志记录了所有执行时间超过指定参数(longquerytime，单位:秒，默认10秒)的所有SOL语句的日志------------------>要自定义参数可看下文【3.profile详情】
慢查询日志的作用：一段操作后，我们可以在其中定位到效率比较低的sql，从而进行优化
MySQL的慢查询日志默认没有开启需要在MySQL的配置文件(/etc/my.cnf)中配置如下信息:
配置完毕之后，通过以下指令重新启动MSQL服务器进行测试，查看慢日志文件中记录的信息/var/lib/mysql/localhost-slow.log。

【2】演示：查看慢查询日志开关是否开启

c 复制代码

show variables like 'slow query log';

【2】演示：Linux中配置慢查询日志

登录linux，编辑mysql下的配置文件：/etc/my.cnf
大G跳到最后
输入

c 复制代码

slow_query_log=1
long_query_time=2

重新连接后；再次查询，发现接口已开启

【3】演示：实时监测慢查询日志

我们开启两个窗口，第一个窗口输入如下代码查看慢查询日志实时情况

c 复制代码

tail -f localhost-slow.1og

第二个窗口执行一条select语句，由于用时没有超过10s，所以在第一个窗口中没有显示
第二个窗口执行一条典型性能低select语句，用时超过10s，所以在第一个窗口中显示

3.profiles详情------（解决慢查询日志--自定义问题）

【1】慢查询日志机理机理＆作用＆语法

慢查询日志只记录超过10s的sql记录，想要自定义要通过profiles
show profiles 能够在做SQL优化时帮助我们了解时间都耗费到哪里去了
通过have profiling参数，能够看到当前MySQL是否支持profile操作：

c 复制代码

SELECT @@have_profiling ;

默认profiling是关闭的，可以通过set语句在session/global级别开启profiling
通过以下语句，能够看到当前profile操作是否开启

c 复制代码

SET profiling=1;

查看profiling状态

cpp 复制代码

select @profiling;

执行一系列的业务SQL的操作，然后通过如下指令查看指令的执行耗时:

【2】演示：打开profiles开关前后对比

【3】演示：执行一系列的业务SQL的操作，然后通过profile查看指令的执行耗时/各个阶段耗时/CPU使用情况:

执行一系列sql语句
查询profiles
我们想知道最后一条语句，为何花了9s多，耗费在哪些地方，我们可以接着操作
加上cpu，可以查看指定query id的SQL语句CPU的使用情况

4.explain执行计划（最常用）

【1】explain执行计划＆语法

EXPLAIN 或者 DESC命令获取 MySQL如何执行 SELECT语句的信息，包括在 SELECT语句执行过程中表如何连接和连接的顺序。

【2】explain执行计划演示

在select语句前加入explain或desc即可

【3】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
possible_key：显示可能应用在这张表上的索引，一个或多个
Key：实际使用的索引，如果为NULL，则没有使用索引。
Key_len：表示索引中使用的字节数，该值为索引字段最大可能长度，并非实际使用长度，在不损失精确性的前提下，长度越短越好
rows：MySQL认为必须要执行查询的行数，在innodb引擎的表中，是一个估计值，可能并不总是准确的
filtered ：表示返回结果的行数占需读取行数的百分比，filtered 的值越大越好。