MySQL数据库学习笔记,超详细!!(4)

Java小白开始学习MySQL数据库,一方面,跟着视频学习,并记录下学习笔记,方便以后复习回顾。另一方面,发布学习笔记来约束自己,学习路程还很遥远,继续加油坚持!!!希望能帮助到大家!

本次更新MySQL的存储引擎,索引,包括索引的结构,索引的分类(聚集索引、二级索引),索引的使用以及索引的设计原则

上期链接MySQL数据库学习笔记,超详细!!(3)

另外还有我的牛客Java专项练习笔记专栏Spring框架学习专栏也在同步更新,希望大家多多关注,一起学习!!!

7. 存储引擎

7.1 MySQL体系结构

  • 连接层

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

  • 服务层

第二层架构主要完成大多数的核心服务功能,如SQL接口,并完成缓存的查询,SQL的分析和优化,部分内置函数的执行。所有跨存储引擎的功能也在这一层实现,如过程、函数等。在该层,服务器会解析查询并创建相应的内部解析树,并对其完成相应的优化如确定表的查询的顺序,是否利用索引等,最后生成相应的执行操作。如果是select语句,服务器还会查询内部的缓存,如果缓存空间足够大,这样在解决大量读操作的环境中能够很好的提升系统的性能。

  • 引擎层

存储引擎层,存储引擎真正的负责了MySQL中数据的存储和提取,服务器通过API和存储引擎进行通信。不同的存储引擎具有不同的功能,这样我们可以根据自己的需要,来选取合适的存储引擎。数据库中的索引是在存储引擎层实现的。

  • 存储层

数据存储层, 主要是将数据(如: redolog、undolog、数据、索引、二进制日志、错误日志、查询日志、慢查询日志等)存储在文件系统之上,并完成与存储引擎的交互。

7.2 存储引擎介绍

存储引擎就是存储数据、建立索引、更新/查询数据等技术的实现方式。存储引擎是基于表的,而不是基于库的,所以存储引擎也可被称为表类型。我们可以在创建表的时候,来指定选择的存储引擎,如果没有指定将自动选择默认的存储引擎。

  • 建表时指定存储引擎

CREATE TABLE 表名(
    字段1 字段1类型 [COMMENT 字段1注释],
    ......
    字段n 字段n类型 [COMMENT 字段n注释]
) ENGINE = INNODB [COMMENT 表注释];
  • 查询当前数据库支持的存储引擎

show engines;

案例:

-- 创建表 my_myisam , 并指定MyISAM存储引擎
create table my_myisam(
    id int,
    name varchar(10)
) engine = MyISAM ;

7.3 存储引擎特点

7.3.1 InnoDB
  1. 介绍

InnoDB是一种兼顾高可靠性和高性能的通用存储引擎,在MySQL 5.5之后,InnoDB是默认的MySQL存储引擎。

  1. 特点:

  • DML操作遵循ACID模型,支持事务

  • 行级锁,提高并发访问性能

  • 支持外键FOREIGN KEY约束,保证数据的完整性和正确性;

  1. 文件:

xxx.ibd:xxx代表的是表名,innoDB引擎的每张表都会对应这样一个表空间文件,存储该表的表结构(frm-早期的 、sdi-新版的)、数据和索引。

参数:innodb_file_per_table,如果该参数开启,代表对于InnoDB引擎的表,每一张表都对应一个ibd文件。

show variables like 'innodb_file_per_table';
  1. 逻辑存储结结构

  • 表空间(TableSpace):InnoDB存储引擎逻辑结构的最高层,ibd文件其实就是表空间文件,在表空间中可以包含多个Segment段。

  • 段(Segment):表空间由各个段组成,常见的段有数据段、索引段、回滚段等。InnoDB中对于段的管理,都是引擎自身完成的,一个段中包含多个区。

  • 区(Extent):区是表空间的单元结构,每个区的大小为1M。默认情况下InnoDB存储引擎页的大小为16K,即一个区中有64个连续的页

  • 页(Page):页是组成区的最小单元,==页也是InnoDB存储引擎磁盘管理的最小单元==,每个页的大小默认为16KB,为了保证页的连续性,InnoDB存储引擎每次从磁盘申请4-5个区。

  • 行(Row):InnoDB 存储引擎是面向行的,也就是说数据是按行进行存放的,在每一行中除了定义表时所指定的字段以外,还包含两个隐藏字段。

7.3.2 MyISAM
  1. 介绍

MyISAM是MySQL早期的默认存储引擎。

  1. 特点

  • 不支持事务,不支持外键

  • 支持表锁,不支持行锁

  • 访问速度快

  1. 文件

  • xxx.sdi:存储表结构信息

  • xxx.MYD: 存储数据

  • xxx.MYI: 存储索引

7.3.3 Memory
  1. 介绍

Memory引擎的表数据时存储在内存中的,由于受到硬件问题、或断电问题的影响,只能将这些表作为临时表或缓存使用。

  1. 特点

  • 内存存放

  • hash索引(默认)

  1. 文件

  • xxx.sdi:存储表结构信息

7.3.4 区别
InnoDB引擎与MyISAM引擎的区别 ?
InnoDB引擎, 支持事务, 而MyISAM不支持。
InnoDB引擎, 支持行锁和表锁, 而MyISAM仅支持表锁, 不支持行锁。
InnoDB引擎, 支持外键, 而MyISAM是不支持的。

8 索引

8.1 索引概述

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

8.1.1 演示

执行语句:select * from user where age = 45;

  • 无索引情况

在无索引情况下,就需要从第一行开始扫描,一直扫描到最后一行,我们称之为 全表扫描,性能很低。

  • 有索引情况

如果我们针对于这张表建立了索引,假设索引结构就是二叉树,那么也就意味着,会对age这个字段建立一个二叉树的索引结构。

此时我们在进行查询时,只需要扫描三次就可以找到数据了,极大的提高的查询的效率。

8.1.2 特点

优势

劣势

提高数据库检索的效率,降低数据库的IO成本

索引列也是要占空间的

通过索引列对数据进行排序,降低数据排序的成本,降低CPU的消耗

索引大大的提高了查询效率,同时却也降低了更新表的速度,如对表进行INSERT、UPDATE、DELETE时,效率降低

8.2 索引结构

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

索引结构

描述

B+Tree索引

最常见的索引类型,大部分引擎都支持B+树

Hash索引

底层数据结构是用哈希表实现的, 只有精确匹配索引列的查询才有效, 不支持范围查询

R-Tree(空间索引)

空间索引是MyISAM引擎的一个特殊索引类型,主要用于地理空间数据类型,通常使用较少

Full-text(全文索引)

是一种通过建立倒排索引,快速匹配文档的方式。类似于Lucene,Solr,ES

8.2.1 二叉树

缺点:

  • 顺序插入时,会形成一个链表,查询性能大大降低。

  • 大数据量情况下,层级较深,检索速度慢

红黑树缺点:大数据量情况下,层级较深,检索速度慢。

8.2.2 B-Tree

B-Tree,B树是一种==多叉路衡查找树==,相对于二叉树,B树每个节点可以有多个分支,即多叉。

以一颗最大度数(max-degree)为5(5阶)的b-tree为例,那这个B树每个节点最多存储4个key,5个指针:

插入100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88 120 268 250数据

特点:

  • 5阶的B树,每一个节点最多储存4个key,对应5个指针

  • 一旦节点存储的key到达5,就会裂变,中间元素向上分裂

  • 在B树中,非叶子节点和叶子节点都会存放数据

8.2.3 B+Tree

B+Tree是B-Tree的变种,我们以一颗最大度数(max-degree)为4(4阶)的b+tree为例,其结构示意图:

插入100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88 120 268 250数据

B+Tree 与 B-Tree相比,主要有以下三点区别:

  • 所有的数据都会出现在叶子节点

  • 叶子节点形成一个单向链表

  • 非叶子节点仅仅起到索引数据的作用,具体的数据都是在叶子节点存放的

上述所看到的结构是标准的B+Tree的数据结构,接下来,看看MySQL中优化之后的B+Tree。

MySQL索引数据结构对经典的B+Tree进行了优化。在原B+Tree的基础上,增加一个指向相邻叶子节点的链表指针,==就形成了带有顺序指针的B+Tree==,提高区间访问的性能,利于排序。

8.2.4 Hash

MySQL中除了支持B+Tree索引,还支持一种索引类型---Hash索引。

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

如果两个(或多个)键值,映射到一个相同的槽位上,他们就产生了hash冲突(也称为hash碰撞),可以通过链表来解决。

  1. 特点

  • Hash索引值只能用于对等比较(= in),不支持范围查询(between,>,<,...)

  • 无法利用索引完成排序操作

  • 查询效率高,通常(不存在hash冲突的情况)只需要一次检测就可以了,效率通常要高于B+Tree索引

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

8.3 索引分类

8.3.1 索引分类

在MySQL数据库中,将索引的具体类型主要分为以下几类:主键索引、唯一索引、常规索引、全文索引

分类

含义

特点

关键字

主键索引

针对表中主键创建的索引

默认自动创建,只能有一个

PRIMARY

唯一索引

避免同一个表中某数据列中的值重复

可以有多个

UNIQUE

常规索引

快读定位特定数据

可以有多个

全文索引

全文索引查找的是文本中的关键词,而不是比较索引中的值

可以有多个

FULLTEXT

8.3.2 聚集索引、二级索引

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

分类

含义

特点

聚集索引(Clustered Index)

将数据存储与索引放到了一块,索引结构的叶子节点保存了行数据

必须有,而且只有一个

二级索引(Secondary Index)

将数据与索引分开存储,索引结构的叶子节点关联的是对应的主键

可以存在多个

聚集索引选取规则:

  • 如果存在主键,主键索引就是聚集索引

  • 如果不存在主键,将使用第一个唯一索引作为聚集索引

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

聚集索引和二级索引的机体结构:

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

当执行如下的SQL语句时,具体的查找过程是:

  1. 由于是根据name字段进行查询,所以先根据name='Arm'到name字段的二级索引中进行匹配查找。但是在二级索引中只能查找到 Arm 对应的主键值 10。

  1. 由于查询返回的数据是*,所以此时,还需要根据主键值10,到聚集索引中查找10对应的记录,最终找到10对应的行row。

  1. 最终拿到这一行的数据,直接返回即可。

回表查询: 这种先到二级索引中查找数据,找到主键值,然后再到聚集索引中根据主键值,获取数据的方式,就称之为回表查询。
思考:以下两条SQL语句,那个执行效率高? 为什么?
A. select * from user where id = 10 ; B. select * from user where name = 'Arm' ; 备注: id为主键,name字段创建的有索引;
A 语句的执行性能要高于B 语句。
因为A语句直接走聚集索引,直接返回数据。 而B语句需要先查询name字段的二级索引,然后再查询聚集索引,也就是需要进行回表查询。
思考题:InnoDB主键索引的B+tree高度为多高呢?

假设:一行数据大小为1k,一页中可以存储16行这样的数据。InnoDB的指针占用6个字节的空间,主键即使为bigint,占用字节数为8。
高度为2:
n * 8 + (n + 1) * 6 = 16*1024 , 算出n约为 1170
1171 * 16 = 18736
也就是说,如果树的高度为2,则可以存储 18000 多条记录。
高度为3:
1171 * 1171 * 16 = 21939856
也就是说,如果树的高度为3,则可以存储 2200w 左右的记录。

8.4 索引语法

  • 创建索引

CREATE [UNIQUE|FULLTEXT] INDEX 索引名 ON 表名 (字段名1, 字段名2, ...);
  • 查看索引

SHOW INDEX FROM 表名;
  • 删除索引

DROP INDEX 索引名 ON 表名; 

案例:

-- 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_user(profession,age,status);

-- 为email建立合适的索引来提升查询效率。
CREATE INDEX idx_email ON tb_user(email);

查看所有的索引数据:show index from tb_user;

8.5 SQL性能分析

8.5.1 SQL执行频率

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

-- session 是查看当前会话 ;
-- global 是查询全局数据 ;
SHOW GLOBAL STATUS LIKE 'Com_______';
  • Com_delete:删除次数

  • Com_insert:插入次数

  • Com_select:查询次数

  • Com_uodate:更新次数

通过上述指令,我们可以查看到当前数据库到底是以查询为主,还是以增删改为主,从而为数据库优化提供参考依据。如果是以增删改为主,我们可以考虑不对其进行索引的优化。如果是以查询为主,那么就要考虑对数据库的索引进行优化了。
8.5.2 慢查询日志

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

# 开启MySQL慢日志查询开关
slow_query_log=1
# 设置慢日志的时间为2秒,SQL语句执行时间超过2秒,就会视为慢查询,记录慢查询日志
long_query_time=2
select * from tb_user; -- 这条SQL执行效率比较高, 执行耗时 0.00sec
select count(*) from tb_sku; -- 由于tb_sku表中, 预先存入了1000w的记录, count一次,耗时13.35sec

检查慢查询日志:在慢查询日志中,只会记录执行时间超多我们预设时间(2s)的SQL,执行较快的SQL是不会记录的。那这样,通过慢查询日志,就可以定位出执行效率比较低的SQL,从而有针对性的进行优化。

8.5.3 profile详情

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

SELECT @@have_profiling ;

-- 开启profiling
SET profiling = 1;

接下来,我们所执行的SQL语句,都会被MySQL记录,并记录执行时间消耗到哪儿去了。

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

-- 查看每一条SQL的耗时基本情况
show profiles;
-- 查看指定query_id的SQL语句各个阶段的耗时情况
show profile for query query_id;
-- 查看指定query_id的SQL语句CPU的使用情况
show profile cpu for query query_id;
8.5.4 explain

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

  • 语法

-- 直接在select语句之前加上关键字 explain / desc
EXPLAIN SELECT 字段列表 FROM 表名 WHERE 条件 ;

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的值越大越好

8.6 索引使用

8.6.1 最左前缀法则

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

之前创建的tb_user表的索引:

有一个联合索引,这个联合索引涉及三个字段,顺序为:profession、age、status

对于最左前缀法则,查询时,最左边的列,也就是profession列必须存在,否则索引全部失效。而且中间不能跳过某一列,否则该列后面的字段索引将失效。

  • 正常索引

explain select * from tb_user where profession = '软件工程' and age = 31 and status = '0';
explain select * from tb_user where profession = '软件工程' and age = 31;
explain select * from tb_user where profession = '软件工程';

以上的这三组测试中,我们发现只要联合索引最左边的字段 profession存在,索引就会生效,只不过索引的长度不同。 而且由以上三组测试,我们也可以推测出profession字段索引长度为36、age字段索引长度为2、status字段索引长度为4。

  • 索引失效

explain select * from tb_user where status = '0';
explain select * from tb_user where age = 31 and status = '0';

而通过上面的这两组测试,我们也可以看到索引并未生效,原因是因为不满足最左前缀法则,联合索引最左边的列profession不存在。

  • 索引部分失效

explain select * from tb_user where profession = '软件工程' and status = '0';

上述的SQL查询时,存在profession字段,最左边的列是存在的,索引满足最左前缀法则的基本条件。但是查询时,跳过了age这个列,所以后面的列索引是不会使用的,也就是索引部分生效,所以索引的长度就是36。

思考:
当执行SQL语句: explain select * from tb_user where age = 31 and status = '0' and profession = '软件工程';时,是否满足最左前缀法则,走不走上述的联合索引,索引长度?

可以看到,是完全满足最左前缀法则的,索引长度54,联合索引是生效的。
注意 :
最左前缀法则中指的最左边的列,是指在查询时,联合索引的最左边的字段(即是第一个字段)必须存在,与编写SQL时,条件编写的先后顺序无关。
8.6.2 范围查询

联合索引中,出现范围查询(>,<),范围查询右侧的列索引失效。

explain select * from tb_user where profession = '软件工程' and age > 30 and status = '0';

当范围查询使用> 或 < 时,走联合索引了,但是索引的长度为38,就说明范围查询右边的status字段是没有走索引的。

当范围查询使用> = 或 < = 时,走联合索引了

explain select * from tb_user where profession = '软件工程' and age > = 30 and status = '0';

索引长度为42,说明所有的字段都是走的索引

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

8.6.3 索引失效情况
8.6.3.1 索引列失效

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

-- 当根据phone字段进行等值匹配查询时, 索引生效。
explain select * from tb_user where phone = '17799990015';

-- 当根据phone字段进行函数运算操作之后,索引失效。
explain select * from tb_user where substring(phone,10,2) = '15';
8.6.3.2 字符串不加引号

字符串类型字段使用时,不加引号,索引将失效。

explain select * from tb_user where phone = '17799990015';

explain select * from tb_user where phone = 17799990015;

经过上面两组示例,我们会明显的发现,如果字符串不加单引号,对于查询结果,没什么影响,但是数据库存在隐式类型转换,索引将失效。

8.6.3.3 模糊查询

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

由于下面查询语句中,都是根据profession字段查询,符合最左前缀法则,联合索引是可以生效的,主要看一下,模糊查询时,%加在关键字之前,和加在关键字之后的影响。

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模糊查询中,在关键字后面加%,索引可以生效。而如果在关键字前面加了%,索引将会失效。

8.6.3.4 or连接的条件

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

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

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

最终,我们发现,当or连接的条件,左右两侧字段都有索引时,索引才会生效。

8.6.3.5 数据分布影响

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

explain select * from tb_user where phone > = '17799990005';
explain select * from tb_user where phone > = '17799990015';

因为MySQL在查询时,会评估使用索引的效率与走全表扫描的效率,如果走全表扫描更快,则放弃索引,走全表扫描。 因为索引是用来索引少量数据的,如果通过索引查询返回大批量的数据,则还不如走全表扫描来的快,此时索引就会失效。

8.6.4 SQL提示

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

  • use index:建议MySQL使用哪一个索引完成此次查询(仅仅是建议,mysqsl内部还会再次进行评估)

explain select * from tb_user use index(idx_user_pro) where profession = '软件工程';
  • ignore index:忽略指定索引

explain select * from tb_user ignore index(idx_user_pro) where profession = '软件工程';
  • force index:强制使用索引

explain select * from tb_user force index(idx_user_pro) where profession = '软件工程';
8.6.5 覆盖索引

尽量使用覆盖索引,减少select *。 那么什么是覆盖索引呢?

覆盖索引是指:查询使用了索引,并且需要返回的列,在该索引中已经全部能够找到 。

主要关注的是后面的Extra,SQL的结果有:Using where; UsingIndex ; SQL的结果有: Using index condition 。

Extra

含义

Using where;Using Index

查找使用了索引,但是需要的数据在索引列中能找到,所以不需要回表查询

Using Index condition

查找使用了索引,但是需要回表查询

因为,在tb_user表中有一个联合索引 idx_user_pro_age_sta,该索引关联了三个字段profession、age、status,而这个索引也是一个二级索引,所以叶子节点下面挂的是这一行的主键id。 所以当我们查询返回的数据在 id、profession、age、status 之中,则直接走二级索引直接返回数据了。 如果超出这个范围,就需要拿到主键id,再去扫描聚集索引,再获取额外的数据了,这个过程就是回表。 而我们如果一直使用select * 查询返回所有字段值,很容易就会造成回表查询(除非是根据主键查询,此时只会扫描聚集索引)。

案例:SQL执行过程

  • 表结构及索引示意图:

id是主键,是一个聚集索引。 name字段建立了普通索引,是一个二级索引(辅助索引)。

  • 执行SQL : select * from tb_user where id = 2;

根据id查询,直接走聚集索引查询,一次索引扫描,直接返回数据,性能高。

  • 执行SQL:selet id, name from tb_user where name = 'Arm';

虽然是根据name字段查询,查询二级索引,但是由于查询返回在字段为 id,name,在name的二级索引中,这两个值都是可以直接获取到的,==因为覆盖索引,所以不需要回表查询==,性能高。

  • 执行SQL:selet id,name,gender from tb_user where name = 'Arm';

由于在name的二级索引中,不包含gender,所以,需要两次索引扫描,也就是需要回表查询,性能相对较差一点。

思考:
一张表, 有四个字段(id, username, password, status), 由于数据量大, 需要对以下SQL语句进行优化, 该如何进行才是最优方案:
select id,username,password from tb_user where username = 'zhangsan';
答案: 针对于 username, password建立联合索引,
create index idx_user_name_pass on tb_user(username,password);
这样可以避免上述的SQL语句,在查询的过程中,出现回表查询。
8.6.6 前缀索引

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

  • 语法

create index idx_xxx on 表名(column(n));
-- 为tb_user表的email字段,建立长度为5的前缀索引。
create index idx_email_5 on tb_user(email(5));
  • 前缀长度

可以根据索引的选择性来决定,而选择性是指不重复的索引值(基数)和数据表的记录总数的比值,索引选择性越高则查询效率越高,唯一索引的选择性是1,这是最好的索引选择性,性能也是最好的。

select count(distinct email) / count(*) from tb_user ;

select count(distinct substring(email,1,5)) / count(*) from tb_user ;
  • 前缀索引查询流程

8.6.7 单列索引和联合索引

单列索引:即一个索引只包含单个列

联合索引:即一个索引包含了多个列

在业务场景中,如果存在多个查询条件,考虑针对于查询字段建立索引时,建议建立联合索引,而非单列索引。

8.7 索引设计原则

  • 针对数据量较大,且查询比较频繁的表建立索引

  • 针对常作为查询条件(where)、排序(order by)、分组(group by)操作的字段建立索引

  • 尽量选择分区度高的列作为索引,尽量建立唯一索引,区分度越高,使用索引的效率越高

  • 如果是字符串类型的字段,字段的长度较长,可以针对于字段的特点,建立前缀索引

  • 尽量使用联合索引,减少单列索引,查询时,联合索引很多时候可以覆盖索引,节省存储空间,避免回表,提高查询效率

  • 要控制索引的数量,索引并不是多多益善,索引越多,维护索引的代价也就越大,会影响增删改的效率

  • 如果索引列不能存储null值,请在创建表时使用NOT NULL约束。当优化器知道每列是否包含null,他可以更好地确定哪个索引最有效的用于查询

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值