记一次sql优化过程

    在一个列表中,用到分页,就用到统计数据,列表不允许重复数据出现,就得用到group by,开始的sql大概是这样的:


很明显,在子查询的时候,生成了一个临时表,当数据量多的情况,慢查就不可避免了。所以,优化在所难免~

其实这是最简单的情况,在列表中还存在搜索条件,有针对对table1的,有针对table2。存在left join 就要尽量降低笛卡尔积,优化之后并带有查询条件的情况,有如下语句:


怎么感觉,除了降低呢笛卡尔积之外就没啥优化空间了呢?

细想一下,其实还是可以继续降低笛卡尔积的,在left join之后,若用where进行连接查询,那么,是先进行笛卡尔积计算,再进行where查找,那么,就可以在left join

之后用and连接查询语句,这样,在left join 之前,会先对table2进行where查找,查找得到的临时表再通table1得到的临时表进行笛卡尔积计算。优化sql如下:



语句大概的优化样子只能这样了,我也暂时想不出更好的sql。

然后运行,测试,发现得到了一些搜索之外的结果集,比如对table2进行where,细想一下,join方式应该是inner join ,只有满足左右表都不为空的情况才是想要的结果集。

最后,改成inner join ,测试无误


总结:where  是left 之后 再过滤  and 是只过滤参与笛卡尔积的后面的表的过滤  不过滤最终查询结果 


在此,感谢酱油哥的帮助

暂时就写到这~~



  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值