简单的php购物网站源码,怎么开发一个小程序,网站集约化建设意见和建议,阿克苏网站怎么做seo前言
最近我在公司优化了一些慢查询SQL#xff0c;积累了一些SQL调优的实战经验。
我之前写过一些SQL优化相关的文章《聊聊SQL优化的15个小技巧》和《explain | 索引优化的这把绝世好剑#xff0c;你真的会用吗#xff1f;》#xff0c;在全网广受好评。
这篇文章从实战…前言
最近我在公司优化了一些慢查询SQL积累了一些SQL调优的实战经验。
我之前写过一些SQL优化相关的文章《聊聊SQL优化的15个小技巧》和《explain | 索引优化的这把绝世好剑你真的会用吗》在全网广受好评。
这篇文章从实战的角度出发给大家分享一下如何做SQL调优。
经过两次优化之后慢SQL的性能显著提升了耗时从8s优化到了0.7s。
现在拿出来给大家分享一下希望对你会有所帮助。
1 案发现场
前几天我收到了一封报警邮件提示有一条慢查询SQL。
我打开邮件查看了详情那条SQL大概是这样的
SELECT count(*)
FROM spu s1
WHERE EXISTS (SELECT *FROM sku s2INNER JOIN mall_sku s3 ON s3.sku_id s2.idWHERE s2.spu_id s1.idAND s2.status 1AND NOT EXISTS (SELECT *FROM supplier_sku s4WHERE s4.mall_sku_id s3.idAND s4.supplier_id 123456789AND s4.status 1)
)这条SQL的含义是统计id123456789的供应商未发布的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 s1inner join from sku s2inner join mall_sku s3 on s3.sku_ids2.idwhere s2.spu_ids1.id and s2.status1and not exists (select * from supplier_sku s4where s4.mall_sku_ids3.idand 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 s1inner join from sku s2inner join mall_sku s3 on s3.sku_ids2.idwhere s2.spu_ids1.id and s2.status1and s3.id not IN (select s4.mall_sku_id from supplier_sku s4where s4.mall_sku_ids3.idand 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调优是一个比较复杂的问题需要考虑的因素有很多有可能需要多次优化才能满足要求。 最后说一句(求关注别白嫖我)
如果这篇文章对您有所帮助或者有所启发的话帮忙扫描下发二维码关注一下您的支持是我坚持写作最大的动力。
求一键三连点赞、转发、在看。
关注公众号【苏三说技术】在公众号中回复面试、代码神器、开发手册、时间管理有超赞的粉丝福利另外回复加群可以跟很多BAT大厂的前辈交流和学习。
