前提准备:本案例准备了100W的数据进行SQL性能测试,数据库采用的是MySQL,
总共介绍了常见的14种SQL优化方式,每一种优化方式都进行了实打实的测试,
逐行讲解,通俗易懂!
一、前提准备
提前准备一张学生表数据和一张特殊学生表数据,用于后面的测试用。
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()
BEGIN
DECLARE i INT DEFAULT 0;
DECLARE done INT DEFAULT 0;
DECLARE continue HANDLER FOR NOT FOUND SET done = 1;
START TRANSACTION;
WHILE i < 1000000 DO
INSERT 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_student_data();
在特殊学生表中随机插入100条学生表中的id:
CREATE PROCEDURE insert_special_student()
BEGIN
DECLARE i INT DEFAULT 0;
WHILE i < 100 DO
INSERT INTO special_student (stu_id) VALUES (FLOOR(RAND()*1000000));
SET i = i + 1;
END WHILE;
END
执行特殊学生表的存储过程:
CALL insert_special_student();
二、SQL优化案例详细介绍
2.1 返回必要的行
如果数量较大,可以使用 LIMIT 子句来限制返回的行数
select id,name from student limit 10
2.2 limit 优化
平日开发工作中,我们对于分页的处理一般是这样的:
SELECT * FROM student LIMIT 900000,10
执行结果如图所示:
耗时0.56s。当id为自增的情况下可以进行优化,优化的SQL如下:
SELECT * FROM student WHERE ID >= 900000 LIMIT 10
优化后执行结果如图所示:
耗时0.02s,速度提升很多!
2.3 返回必要的列,避免使用SELECT *
有的时候,我们为了图方便,会直接使用SELECT * 一次性查出表中所有的数据:
SELECT * FROM student
执行结果如图所示:
可以看到,执行时间花了2s左右,耗时很长!
在实际开发中,我们给页面展示的数据可能就只要2-3个字段,如果直接全部查出来了,岂不是白白浪费了字段,同时也损耗了性能,这是因为SELECT * 不会走覆盖索引,会出现大量的回表操作,从而导致SQL性能大幅度降低。
我们上面建立了联合索引,我们就可以只查询索引列,这样会大幅度提升查询效率,优化的SQL如下:
SELECT name,address,phone FROM student
优化后执行结果如图所示:
耗时0.780s,速度提升很多!
2.4 or连接的条件(注意)
当使用OR操作符将多个条件组合在一起时,如果其中一个条件的列没有索引,那么涉及的索引不会被用到。
为了解决这个问题,可以考虑以下方案:
- 确保所有涉及的条件列都有适当的索引,以提高查询性能。
- 对于大型表,可以考虑重构查询,将OR操作符拆分成多个独立的查询,并使用UNION或UNION ALL来合并结果。这样可以确保每个子查询都能够使用适当的索引,并避免OR操作符导致的索引失效问题。
2.5 避免使用or条件,使用UNION或UNION ALL替代(有争议)
如果我们要查询指定的性别或者指定的身份证号码的学生,执行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'
改用后执行结果如图所示:
速度没有提升,反而慢了,故有争议
分析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的,我这边实测感觉还是存在争议的!
2.6 非必要情况下,慎用UNION关键字,使用UNION ALL替代
例如我们根据性别去查询所有学生的信息,虽然这种操作多此一举,直接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左右!
速度提升很多!
2.7 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'
执行结果如图所示:
依旧走了全表扫描!
使用EXPLAIN关键字执行这段SQL:
EXPLAIN SELECT * FROM student WHERE id_card like '50%'
执行结果如图所示:
这次便走了索引!速度快很多
2.8 尽量避免使用!=,导致索引失效
尽量避免使用!=或<>操作符,下面直接分析SQL:
SQL分析:
使用EXPLAIN关键字执行这段SQL:
EXPLAIN SELECT * FROM student WHERE id_card != '5031520645'
执行结果如图所示:
虽然我们给了id_card字段建立了索引,但还是走了全表扫描!
2.9 尽量避免使用NULL值,IS NOT NULL会导致索引失效,IS 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
执行结果如图所示:
这样是走索引的!
2.10 使用小表驱动大表 ,避免大表驱动小表
言简意赅,意思就是让小表查出来的数据去再查询大表当中的数据。比如我们想查询学生表当中特殊学生的信息,我们就可以使用以special_student这个小表去驱动student这个大表,SQL如下:
SELECT * FROM student WHERE id
IN (SELECT stu_id FROM special_student)
执行结果如图所示:
只用了0.02s,速度很可观!因为IN关键字中的子查询语句,子查询语句的数据量很少,所以查询速度会很快!
2.11 避免字符串不加引号,导致索引失效
如果在查询条件或创建索引时字符串没有加上引号,会导致索引失效。
查询指定的身份证号码的学生,如果我们平时疏忽了给身份证号码加上单引号,执行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'
执行结果如图所示:
加上引号,走了索引,速度快了很多!
2.12 避免对索引列上字段操作,导致索引失效
为了避免索引失效的问题,应该尽量避免在查询条件或者索引创建时对索引列进行运算。如果确实需要使用运算,可以考虑以下解决方案:
- 对索引列进行逆转运算:如果运算是可逆的,可以通过将运算应用到查询参数上,而不是索引列上来维持索引的有效性。
- 使用函数索引:某些数据库管理系统提供了函数索引的功能,可以根据特定的函数操作创建索引,以满足特定的查询需求。
2.13 遵循最左匹配原则(重要)
上面我们按照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'
2.14 提升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左右,虽然不明显,也是一种不错的思路。