一次显著的性能提升,从8s到0.7s

今天从实战的角度出发,给大家分享一下如何做SQL调优。

经过两次优化之后,慢SQL的性能显著提升了,耗时从 8s 优化到了 0.7s

1 案发现场

前几天,我收到了一封报警邮件,提示有一条慢查询SQL。

我打开邮件查看了详情,那条SQL大概是这样的:

SELECT count(*)
FROM spu s1
WHERE EXISTS (
 SELECT *
 FROM sku s2
  INNER JOIN mall_sku s3 ON s3.sku_id = s2.id
 WHERE s2.spu_id = s1.id
  AND s2.status = 1
  AND NOT EXISTS (
   SELECT *
   FROM supplier_sku s4
   WHERE s4.mall_sku_id = s3.id
    AND s4.supplier_id = 123456789
    AND s4.status = 1
  )
)

这条SQL的含义是统计id=123456789的供应商,未发布的spu数量是多少。

这条SQL的耗时竟然达标了 8s ,必须要做优化了。

我首先使用 explain 关键字查询该SQL的 执行计划 ,发现spu表走了type类型的索引,而sku、mall_sku、supplier_sku表都走了ref类型的索引。

也就是说,这4张表都走了 索引

不是简单的增加索引就能解决的事情。

那么,接下来该如何优化呢?

2 第一次优化

这条SQL语句,其中两个 exists 关键字引起了我的注意。

一个 exists 是为了查询存在某些满足条件的商品,另一个 not exists 是为了查询出不存在某些商品。

这个SQL是另外一位已离职的同事写的。

不清楚spu表和sku表为什么不用join,而用了exists。

我猜测可能是为了只返回spu表的数据,而做的一种处理。如果join了sku表,则可能会查出重复的数据,需要做去重处理。

从目前看,这种写性能有瓶颈。

因此,我做出了第一次优化。

使用 join + group by 组合,将sql优化如下:

SELECT count(*) FROM
(
  select s2.spu_id from spu s1
  inner join from sku s2
  inner join mall_sku s3 on s3.sku_id=s2.id
  where s2.spu_id=s1.id ans s2.status=1
  and not exists 
  (
     select * from supplier_sku s4
     where s4.mall_sku_id=s3.id
     and s4.supplier_id=...
  )
  group by s2.spu_id
) a

文章中有些相同的条件省略了,由于spu_id在sku表中是增加了索引的,因此group by的性能其实是挺快的。

这样优化之后,sql的执行时间变成了 2.5s

性能提升了3倍多,但还是不够快,还需要做进一步优化。

3 第二次优化

还有一个not exists可以优化一下。

如果是小表驱动大表的时候,使用not exists确实可以提升性能。

但如果是大表驱动小表的时候,使用not exists可能有点弄巧成拙。

这里exists右边的sql的含义是查询某供应商的商品数据,而目前我们平台一个供应商的商品并不多。

于是,我将not exists改成了not in。

sql优化如下:

SELECT count(*) FROM
(
  select s2.spu_id from spu s1
  inner join from sku s2
  inner join mall_sku s3 on s3.sku_id=s2.id
  where s2.spu_id=s1.id ans s2.status=1
  and s3.id not IN 
  (
     select s4.mall_sku_id 
     from supplier_sku s4
     where s4.mall_sku_id=s3.id
     and s4.supplier_id=...
  )
  group by s2.spu_id
) a

这样优化之后,该sql的执行时间下降到了0.7s。

之后,我再用explain关键字查询该SQL的执行计划。

发现spu表走了全表扫描,sku表走了eq_ref类型的索引,而mall_sku和supplier_sku表走了ref类型的索引。

可以看出,有时候sql语句走了4个索引,性能未必比走了3个索引好。

多张表join的时候,其中一张表走了全表扫描,说不定整个SQL语句的性能会更好,我们一定要多测试。

说实话,SQL调优是一个比较复杂的问题,需要考虑的因素有很多,有可能需要多次优化才能满足要求。

相关推荐
customer0810 分钟前
【开源免费】基于SpringBoot+Vue.JS医疗报销系统(JAVA毕业设计)
java·vue.js·spring boot·后端·开源
barcke19 分钟前
【深度解析】Java接入DeepSeek大模型:从零实现流式对话+多轮会话管理(完整项目实战) —— SpringBoot整合、API安全封装、性能优化全攻略
java·spring boot
卷心菜不卷Iris22 分钟前
第1章大型互联网公司的基础架构——1.9 LSM Tree
数据库·lsm-tree·互联网大厂·基础架构
小赖同学啊30 分钟前
jmeter 与大数据生态圈中的服务进行集成
大数据·jmeter
zl97989931 分钟前
MybatisPlus-注解
java·spring·maven
杰九41 分钟前
【环境配置】maven,mysql,node.js,vue的快速配置与上手
java·vue.js·spring boot·mysql·node.js·maven
wapicn991 小时前
‌挖数据平台对接DeepSeek推出一键云端部署功能:API接口驱动金融、汽车等行业智能化升级
java·人工智能·python·金融·汽车·php
闲人编程1 小时前
Spark单机快速入门:从部署到数据分析实战
大数据
GISer_Qing1 小时前
ASP.NET Core 8.0学习笔记(二十七)——数据迁移:Migrations深入与其他迁移命令
数据库·c#·.netcore·entityframework
蓝桉8021 小时前
图片爬取案例
开发语言·数据库·python