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 and 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 and 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调优是一个比较复杂的问题,需要考虑的因素有很多,有可能需要多次优化才能满足要求。