sql改下优化

xnk9499

aeoluspu 发表于 2012-12-6 09:28
not exists 与not in 在效率方面没有太多差别吧 ？

你可以看看优化方面的建议
基本是不建议使用not in的

草民的补丁

xnk9499 发表于 2012-12-5 20:29
用not exists替换not in
is_drop 添加为索引

is_drop上有索引了，呵呵，not exists的话，效果和not in差不多，就是想把not in转换出去，因为使用的都是一张表中的数据。

aeoluspu

not in 优化都是优化为 left join ，如果感觉还是不行 ，那就看看 业务逻辑上是不是可以有优化的地方

草民的补丁

aeoluspu 发表于 2012-12-6 11:43
not in 优化都是优化为 left join ，如果感觉还是不行 ，那就看看 业务逻辑上是不是可以有优化的地方

嗯，呵呵

G8bao7

草民的补丁 发表于 2012-12-6 09:58
is_drop上有索引了，呵呵，not exists的话，效果和not in差不多，就是想把not in转换出去，因为使用的都是 ...

一点疑问：group by的作用没体现出来，

一、在t1中先进行 group by，减少t1的结果集数量
(SELECT t.gem_code FROM gem_picture t WHERE t.is_cover=1 AND t.is_drop=0 GROUP BY t.gem_code) AS t1

二、这样还不行的话，应该就和表中的数据分布有关了

满足t.is_drop=0 、t.is_cover=1 AND t.is_drop=0 这两个条件的数据量占全表数据量的比例比较高，即使is_drop=0有索引，也会进行全表扫描

可以反向考虑尝试下。
由于WHERE  k.is_drop=0这个条件是无法改变的，只能改变join的 t1结果集
LEFT OUTER JOIN (SELECT t.gem_code FROM gem_picture t
    WHERE t.is_drop!=0 or (t.is_cover!=1 AND t.is_drop=0)
) AS t1 ON k.gem_code=t1.gem_code
WHERE  k.is_drop=0 AND t1.gem_code IS NOT NULL

草民的补丁

G8bao7 发表于 2012-12-6 13:39
一点疑问：group by的作用没体现出来，

一、在t1中先进行 group by，减少t1的结果集数量

嗯，谢谢兄弟拍砖，哈，这里估计主要是业务数据分布的问题，按照以上条件索取的话，耗时还是很多！以下是截图信息！

草民的补丁

草民的补丁 发表于 2012-12-6 14:02
嗯，谢谢兄弟拍砖，哈，这里估计主要是业务数据分布的问题，按照以上条件索取的话，耗时还是很多！以下是 ...

以下是我用profile的统计在正式上所得！可以看到Copying to tmp table，值比较大，现在数据量比较少，以后数据加大，估计会影响数据，优化不了，数据大了要做数据切割。NND!

G8bao7

草民的补丁 发表于 2012-12-6 14:13
以下是我用profile的统计在正式上所得！可以看到Copying to tmp table，值比较大，现在数据量比较少，以后 ...

最后的sorting占用比例也不小，group by 默认是进行排序的，如果不需要排序的话，最后可以加上 order by NULL

G8bao7

草民的补丁 发表于 2012-12-6 14:13
以下是我用profile的统计在正式上所得！可以看到Copying to tmp table，值比较大，现在数据量比较少，以后 ...

还有，关于这点
一、在t1中先进行 group by，减少t1的结果集数量

如果t1 进行group by后，结果集减少的比较少，加上group反而效率会更低。
根据gem_code分布酌情考虑

草民的补丁

G8bao7 发表于 2012-12-6 14:36
还有，关于这点
一、在t1中先进行 group by，减少t1的结果集数量

嗯，好的，