sql优化的方法

目录

一、准备数据

1.1、创建表结构

1.2、创建存储过程 

  二、索引介绍

2.1、类型介绍

2.2、建立索引

2.3、建立复合索引

2.4、查看所有建立的索引

2.5、删除索引

三、EXPLAIN分析参数说明

四、SQL优化案例

4.1、避免使用SELECT *

4.2、慎用UNION关键字

4.4、避免使用or条件（有争议）

4.5、LIKE语句优化

4.6、字符串字段优化

4.7、最左匹配原则（重要）

4.8、COUNT查询数据是否存在优化 

4.9、LIMIT关键字优化 

4.10、提升GROUP BY的效率

4.11、避免使用!=或<>

4.12、避免NULL值判断

4.13、避免函数运算

4.14、JOIN的表中使用索引字段

4.15、用EXISTS代替IN

一、准备数据

提前准备一张学生表数据和一张特殊学生表数据，用于后面的测试用。

1.1、创建表结构

创建一个学生表：

CREATE TABLE student (id int(11) unsigned NOT NULL AUTO_INCREMENT,name varchar(50) DEFAULT NULL,age tinyint(4) DEFAULT NULL,id_card varchar(20) DEFAULT NULL,sex tinyint(1) DEFAULT '0', address varchar(100) DEFAULT NULL,phone varchar(20) DEFAULT NULL, create_time timestamp NULL DEFAULT CURRENT_TIMESTAMP,remark varchar(200) DEFAULT NULL,PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

再创建一个特殊学生表：

CREATE TABLE special_student (id int(11) unsigned NOT NULL AUTO_INCREMENT,stu_id int(11) DEFAULT NULL,PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

1.2、创建存储过程 

在学生表中插入100w条数据，手动开启和提交事务，每插入1w条记录后，手动COMMIT一次事务，最后再COMMIT一次以提交剩下的记录，这样可以让插入速度更快,因为不需要为每条记录都 COMMIT,从而降低 IO 次数。

CREATE PROCEDURE insert_student_data()
BEGINDECLARE i INT DEFAULT 0; DECLARE done INT DEFAULT 0; DECLARE continue HANDLER FOR NOT FOUND SET done = 1;START TRANSACTION;  WHILE i < 1000000 DOINSERT INTO student(name,age,id_card,sex,address,phone,remark)VALUES(CONCAT('姓名_',i), FLOOR(RAND()*100),FLOOR(RAND()*10000000000),FLOOR(RAND()*2),CONCAT('地址_',i), CONCAT('12937742',i),CONCAT('备注_',i));SET i = i + 1; IF MOD(i,10000) = 0 THEN COMMIT;START TRANSACTION;END IF;     END WHILE;    COMMIT;
END

 执行特殊学生表的存储过程： 

CALL insert_special_student();

  二、索引介绍

2.1、类型介绍

普通索引    最基本的索引，没有任何限制
唯一索引    与普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值
主索引    即主键索引，关键字PRIMARY
复合索引    为了更多的提高MySQL效率可建立组合索引，遵循“最左前缀”原则
全文索引    可用于MyISAM表，MySQL5.6之后也可用于innodb表，用于在一篇文章中，检索文本信息的, 针对较大的数据，生成全文索引很耗时和空间

2.2、建立索引

CREATE INDEX id_card_index ON student(id_card);

2.3、建立复合索引

CREATE INDEX name_address_phone_index ON student(name,address,phone);

2.4、查看所有建立的索引

SHOW INDEX FROM student;

2.5、删除索引

ALTER TABLE 表名 DROP INDEX 索引名称;

三、EXPLAIN分析参数说明

1、id：SELECT语句的编号。可以通过id来区别多条SELECT语句。

2、select_type：SELECT类型，主要有SIMPLE、PRIMARY、DERIVED等类型。

SIMPLE：简单的SELECT（不含子查询及UNION）。

PRIMARY：查询中最外层的SELECT。

DERIVED：包含的子查询中的SELECT。

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

4、partitions：匹配的分区信息。

5、type：显示连接使用了何种类型。

最好到最差的连接类型为 system > const > eq_reg > ref > range > index > ALL.

system

表只有一行记录(等于系统表)
const使用常量进行索引查询
eq_ref唯一索引扫描，通常使用主键约束
ref非唯一性索引扫描
range索引范围扫描
index全索引扫描
ALL全表扫描

6、possible_keys：显示可能应用在这张表中的索引。

7、key：实际使用的索引。

8、key_len：使用的索引的长度。

9、ref：显示索引的哪一列被使用。

10、rows：根据表统计信息及索引条件估算，查询返回的且接近的行数

11、filtered：显示了通过条件过滤出的行数的百分比估计值。

12、Extra：包含不适合在其他列展示但是需要展示的信息。

四、SQL优化案例

4.1、避免使用SELECT *

有的时候，我们为了图方便，会直接使用SELECT * 一次性查出表中所有的数据：

SELECT * FROM student

执行结果如图所示：

可以看到，执行时间花了2s左右，耗时很长！

在实际开发中，我们给页面展示的数据可能就只要2-3个字段，如果直接全部查出来了，岂不是白白浪费了字段，同时也损耗了性能，这是因为SELECT * 不会走覆盖索引，会出现大量的回表操作，从而导致SQL性能大幅度降低。

我们上面建立了联合索引，我们就可以只查询索引列，这样会大幅度提升查询效率，优化的SQL如下：

SELECT name,address,phone FROM student

执行结果如图所示：

这样执行的速度大大提高！

分析SQL：

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT name,address,phone FROM student

执行结果如图所示：

确实走了我们建立的复合索引。 

4.2、慎用UNION关键字

例如我们根据性别去查询所有学生的信息，虽然这种操作多此一举，直接SELECT *就好了，为了演示这2个关键字的详细区别，使用UNION关键字执行的SQL如下：

SELECT * FROM student WHERE sex = 0
UNION 
SELECT * FROM student WHERE sex = 1

执行结果如图所示： 

我滴妈，查了100w条足足整整等了32s左右，这个速度要是放到系统上，查个数据等到娃娃菜都凉了！

这是因为在使用UNION执行完SQL后，会帮我们获取所有数据并去掉重复的数据，性能的损耗就在这里，而UNION ALL和UNION相反，帮我们获取所有数据但会保留重复的数据。

我们改用UNION ALL关键字，优化的SQL如下：

SELECT * FROM student WHERE sex = 0
UNION ALL
SELECT * FROM student WHERE sex = 1

执行结果如图所示：

同样查询100w条数据，这边执行速度大大提高了，只用到了3s左右！ 

4.3、小表驱动大表 
言简意赅，意思就是让小表查出来的数据去再查询大表当中的数据。比如我们想查询学生表当中特殊学生的信息，我们就可以使用以special_student这个小表去驱动student这个大表，SQL如下：

SELECT * FROM student WHERE id 
IN (SELECT stu_id FROM special_student)

执行结果如图所示：

只用了0.02s，速度很可观！因为IN关键字中的子查询语句，子查询语句的数据量很少，所以查询速度会很快！

4.4、避免使用or条件（有争议）

如果我们要查询指定的性别或者指定的身份证号码的学生，执行SQL如下：

SELECT * FROM student WHERE sex = 0 OR id_card = '7121877527789'

执行结果如图所示：

总共查询了近50w条数据，耗时1.4s左右，我们改用UNION ALL关键字查询：

SELECT * FROM student WHERE sex = 0 
UNION ALL 
SELECT * FROM student WHERE id_card = '7121877527789'

执行结果如图所示：

和上面查询的数据量一样，好事在1.7s左右，怎么会没什么区别呢？

分析SQL： 

使用EXPLAIN关键字分析一下使用OR关键字的这段SQL：

EXPLAIN SELECT * FROM student WHERE SEX = 0 OR id_card = '7121877527789'

执行结果如图所示： 

很明显，虽然可能会用到建立id_card的索引，正因为sex这个字段没有建立索引，还是走了一次全表扫描。

使用EXPLAIN关键字执行这段SQL：

EXPLAIN
SELECT * FROM student WHERE sex = 0 
UNION ALL 
SELECT * FROM student WHERE id_card = '7121877527789'

执行结果如图所示：

很明显条件是sex的走了全表，但是id_card走了索引，所以依旧还是走了一次全表扫描，所以网上说的关于UNION ALL代替OR的，我这边实测感觉还是存在争议的！

4.5、LIKE语句优化

平时我们日常开发用到的LIKE关键字进行模糊匹配会非常多，但是有的情况会使索引失效，导致查询效率变慢，例如：

只要身份证字段包含50就查出来，执行SQL如下：

SELECT * FROM student WHERE id_card like '%50%'

执行结果如图所示：

用了0.8s左右。

只要身份证号码以50结尾就查出来，执行SQL如下：

SELECT * FROM student WHERE id_card like '%50'

执行结果如图所示：

用了0.4s左右。

只要身份证号码以50开头的就查出来，执行SQL如下：

SELECT * FROM student WHERE id_card like '50%'

执行结果如图所示：

这次执行非常快，0.08s左右。

分析SQL：

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card like '%50%'

执行结果如图所示：

很明显走了全表扫描！

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card like '%50'

执行结果如图所示：

这次便走了索引！

4.6、字符串字段优化

查询指定的身份证号码的学生，如果我们平时疏忽了给身份证号码加上单引号，执行SQL如下：

SELECT * FROM student WHERE id_card = 5040198345

执行结果如图所示：

耗时0.4s左右。

给身份证号码加上单引号，优化的SQL如下：

SELECT * FROM student WHERE id_card = '5040198345'

执行结果如图所示：

耗时0.02s左右，这次明显快多了！

分析SQL：

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card = 5040198345

执行结果如图所示：

可能用到了id_card的索引，但是还是走了全表扫描！

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card = '5040198345'
执行结果如图所示： 

这边走了索引。 

这边走了索引。 

4.7、最左匹配原则（重要）

上面我们按照name，address和phone这个顺序建立了复合索引，相当于建立了（name），（name、address）和（name、address、phone）三个索引，如果我们查询的where条件违背了建立的顺序，则复合索引就失效了，下面直接进行SQL分析：

分析SQL：

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE name = '姓名_4' and phone = '7121877527' and address = '地址_4'

执行结果如图：

为什么明明违背了最左匹配原则，依旧还是走了复合索引呢？可能是如下原因：

1、通过索引过滤性能足够好，所以还是选择利用索引。

2、联合索引中前几个字段过滤效果较好，所以仍然选择利用索引。

可能的执行计划大概是：

1、优先通过phone字段过滤，将要扫描的记录减少一部分。
2、然后通过address字段继续过滤,再减少一部分记录。
3、最后通过name字段过滤,已经剩下很少的记录需要扫描。
4、尽管违反了最左匹配，解释器可能认为仍然利用索引效率比较高。

所以总的来说，就是解释器会根据实际情况进行权衡，即使是违反最左匹配原则，也可能会选择利用索引。但这并不是一个良好的查询优化，最好还是严格遵守最左匹配原则。

以下是严格遵守最左匹配原则的SQL：

SELECT * FROM student WHERE name = '姓名_4' 
SELECT * FROM student WHERE name = '姓名_4' and address = '地址_4' 
SELECT * FROM student WHERE name = '姓名_4' and address = '地址_4' and phone = '7121877527'

4.8、COUNT查询数据是否存在优化 

比如我想判断年龄为18岁的学生是否存在，我们往往会执行如下SQL：

SELECT COUNT(*) FROM student WHERE age = 18

执行结果如图所示：

耗时0.4s左右，虽然知道学生年龄18岁存在，但是没必要查询出这么多数量出来，我们只要知道是否存在即可！

不再使用COUNT，而是改用LIMIT 1，让数据库查询时遇到一条就返回，这样就不要再继续查找还有多少条了，优化的SQL如下：

SELECT 1 FROM student WHERE age = 18 LIMIT 1

执行结果如图所示：

耗时0.01s左右，很快就知道了。 

4.9、LIMIT关键字优化 

 平日开发工作中，我们对于分页的处理一般是这样的：

SELECT * FROM student LIMIT 999910,10

执行结果如图所示： 

耗时0.56s，但是因为我们的ID属于自增长，所以我们可以在此基础上进行一定的优化，优化的SQL如下： 

SELECT * FROM student WHERE ID >= 999910 LIMIT 10

执行结果如图所示：

仅仅用时0.02s，非常快！

4.10、提升GROUP BY的效率

我们平日写SQL需要多多少少会使用GROUP BY关键字，它主要的功能是去重和分组。 通常它会跟HAVING一起配合使用，表示分组后再根据一定的条件过滤数据，常规执行的SQL如下：

SELECT age,COUNT(1) FROM student GROUP BY age HAVING age > 18

执行结果如图所示：

耗时总计0.53s左右，不过还可以进行优化，我们可以在分组之前缩小筛选的范围，然后再进行分组，优化的SQL如下：

SELECT age,COUNT(1) FROM student where age > 18 GROUP BY age 
执行结果如图所示：

耗时0.51s左右，虽然不明显，也是一种不错的思路。

4.11、避免使用!=或<>

尽量避免使用!=或<>操作符，下面直接分析SQL：

SQL分析：

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card != '5031520645'

执行结果如图所示：

虽然我们给了id_card字段建立了索引，但还是走了全表扫描

4.12、避免NULL值判断

为了确保没有NULL值，我们可以设定一个默认值，下面直接分析SQL：

SQL分析：

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card IS NOT NULL

执行结果如图所示：

依旧还是走了全表扫描。

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE id_card IS NULL

执行结果如图所示：

这样是走索引的！

4.13、避免函数运算

在日常SQL撰写中，在WHERE条件上多多少少会用到一些函数，例如截取字符串，执行SQL如下：

分析SQL： 

使用EXPLAIN关键字执行这段SQL：

EXPLAIN SELECT * FROM student WHERE SUBSTR(id_card,0,9)

执行结果如图所示： 

索引失效，走了全表扫描。 

4.14、JOIN的表中使用索引字段

如果日常开发中，使用JOIN关键字链接表后，使用的ON关键字进行条件链接时，如果条件没有索引，则会进行全表扫描，执行SQL如下：

EXPLAIN SELECT * FROM student a,special_student b WHERE a.id = b.stu_id

执行结果如图所示： 

正因为special_student表的stu_id没有建立索引，则导致了全表扫描！

为stu_id建立索引后，执行SQL如下：

CREATE INDEX stu_id_index ON special_student(stu_id);EXPLAIN SELECT * FROM student a,special_student b WHERE a.id = b.stu_id

执行结果如图所示：  

两张表都走了索引。

4.15、用EXISTS代替IN

IN关键字适合于外表大而内表小的情况，EXISTS适合于外表小而内表大的情

SELECT * FROM special_student 
WHERE EXISTS 
( SELECT 1 FROM student WHERE special_student.stu_id = student.id)

况，执行SQL如下：

运行结果如图所示：

执行效率在0.02s左右，这里special_student是小表，student是大表，速度非常快！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/438420.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

响应式架构设计：性能更高更快的架构模式（框架部分后续再完善）

响应式架构设计：性能更高更快的架构模式（框架部分后续再完善）

文章目录 一、初识响应式1、什么是Reactive&#xff08;响应式&#xff09;2、响应式编程&#xff08;Reactive Programming&#xff09;的含义3、响应式编程的特点4、响应式编程的主要模式5、响应式编程的核心元素&#xff08;1&#xff09;流&#xff08;2&#xff09;传播变…
阅读更多...
Nginx 主动检查 被动检查

Nginx 主动检查 被动检查

被动检查 proxy_next_upstream http {upstrean httpget {//max_fail5,失败5词&#xff0c;直接下线 down&#xff0c;//fail_timeout10s, 10s之后 重新上线 up//fail_timeout10s, max_fail5,5次失败在10s内&#xff0c;下线&#xff0c;server IP:80 max_fails5 fail_time…
阅读更多...
除毛可以用宠物空气净化器吗？猫用空气净化器质量高的品牌推荐

除毛可以用宠物空气净化器吗？猫用空气净化器质量高的品牌推荐

如今&#xff0c;越来越多的家庭选择养宠物&#xff0c;因为它们给家里带来了温馨和快乐。然而&#xff0c;宠物也可能带来异味和空气中的浮毛&#xff0c;这可能会给我们的健康带来问题&#xff0c;成为一个困扰。 为了解决家里的异味问题&#xff0c;尤其是宠物的排泄物味道…
阅读更多...
DMA 和 零拷贝技术 到 网络大文件传输优化

DMA 和 零拷贝技术 到 网络大文件传输优化

文章目录 DMA 控制器的发展无 DMA 控制器 IO 过程DMA 控制器 传统文件传输性能有多糟糕&#xff1f;如何优化文件传输性能零拷贝技术mmap writesendfileSG-DMA&#xff08;The Scatter-Gather Direct Memory Access&#xff09; 零拷贝技术的应用 大文件传输应该用什么方式Pag…
阅读更多...
应急响应-流量分析

应急响应-流量分析

在应急响应中&#xff0c;有时需要用到流量分析工具&#xff0c;。当需要看到内部流量的具体情况时&#xff0c;就需要我们对网络通信进行抓包&#xff0c;并对数据包进行过滤分析&#xff0c;最常用的工具是Wireshark。 Wireshark是一个网络封包分析软件。网络封包分析软件的…
阅读更多...
qtcreator使用qwt库

qtcreator使用qwt库

先配置好.pro文件&#xff0c;再去ui界面拖拽控件 ui界面会更改配置&#xff0c;故顺序错一个&#xff0c;就凉了&#xff0c;重来吧 准备&#xff1a;库&#xff0c;库头文件 库文件&#xff1a;路径如下 头文件&#xff1a;路径如下 鼠标->右键 &#xff08;有些不用勾…
阅读更多...
构建知识图谱：从技术到实战的完整指南

构建知识图谱：从技术到实战的完整指南

目录 一、概述二、知识图谱的基础理论定义与分类核心组成历史与发展 三、知识获取与预处理数据源选择数据清洗实体识别 四、知识表示方法知识表示模型RDFOWL属性图模型 本体构建关系提取与表示 五、知识图谱构建技术图数据库选择Neo4jArangoDB 构建流程数据预处理实体关系识别图…
阅读更多...
go语言基础之泛型

go语言基础之泛型

1.泛型 泛型是一种独立于所使用的特定类型的编写代码的方法。使用泛型可以编写出适用于一组类型中的任何一种的函数和类型。 1.1 为什么需要泛型 func reverse(s []int) []int {l : len(s)r : make([]int, l)for i, e : range s {r[l-i-1] e}return r }fmt.Println(reverse…
阅读更多...
基于YOLOv7算法和FLIR数据集的高精度实时红外行人目标检测系统（PyTorch+Pyside6+YOLOv7）

基于YOLOv7算法和FLIR数据集的高精度实时红外行人目标检测系统（PyTorch+Pyside6+YOLOv7）

摘要&#xff1a;基于YOLOv7算法和FLIR数据集的高精度实时红外行人目标检测系统可用于日常生活中检测与定位自行车、汽车、狗和行人目标&#xff0c;此系统可完成对输入图片、视频、文件夹以及摄像头方式的目标检测与识别&#xff0c;同时本系统还支持检测结果可视化与导出。本…
阅读更多...
重生之我是学神，小小c语言 题目可笑可笑

重生之我是学神，小小c语言 题目可笑可笑

阅读更多...
智慧文旅：未来旅游业的数字化转型

智慧文旅：未来旅游业的数字化转型

随着科技的快速发展&#xff0c;数字化转型已经成为各行各业的必然趋势。旅游业作为全球经济的重要组成部分&#xff0c;也正经历着前所未有的变革。智慧文旅作为数字化转型的重要领域&#xff0c;正逐渐改变着旅游业的传统模式&#xff0c;为游客带来更加便捷、个性化的旅游体…
阅读更多...
基于vue实现待办清单案例

基于vue实现待办清单案例

一、需求 新增内容&#xff1b; 删除内容&#xff1b; 统计操作&#xff1b; 清空数据。 示例图&#xff1a; 二、代码演示 1、基础准备 index.css代码 html, body {margin: 0;padding: 0; } body {background: #fff ; } button {margin: 0;padding: 0;border: 0;backgr…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023