一次千万级别的SQL查询简单优化体验

背景:从两张有关联的表查询数据,A表数据量1400万,B表数据量8000万。A与B通过ID逻辑关联,没有实际的外键。B表是后来扩展出来的.

问题:根据某个ID查询时超时,运行时跑不出结果。

原因:使用一个or条件,条件里面有一个是A.ID=B.ID

简单优化:将or条件拆开,使用union all将之前使用表变量的部分换成了临时表对排序的字段加上了索引

结果:在50ms内能够查询出结果,这个与之前的超时简直不能相比。

感想:感谢DBA mm的帮助,让我有了这样的体验,不实际的处理(哪怕很简单的表关系)千万级的数据量,真不知道SQL语句的性能差异。

        实际的体验了使用or的性能居然能够差到这个地步,以后尽量避免使用了。

我没有描述清楚具体的问题,只是大致的说了下。我自己是明白了,记录下来以备后面参考。也希望能够给像我一样的SQL菜菜鸟有点启发。

SQL优化的实践之路还很长,我要慢慢走。工作过程中的体验随时记录下来,分享给大家。

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值