【解决慢SQL历程】

1 篇文章 0 订阅
1 篇文章 0 订阅
文章讨论了SQL查询中存在全表扫描的问题,特别是由于Exists子查询导致的性能下降。优化建议集中在避免对大表v_StoreAlcSchemeDtl的全表扫描,通过调整查询结构将基础表关联移到子查询外部。作者提醒在编写SQL时需注意索引和避免使用大表进行子查询以减少资源消耗。
摘要由CSDN通过智能技术生成

慢SQL优化

慢sql:

Select t.gdCode From TMP_GENDIRALCORD_EXCEL t
  Where Not Exists (select 1 from V_MoreVendorGoods m where m.orggid = 1000000 And m.code = t.gdCode)
    And Not Exists (select 1 from v_StoreAlcSchemeDtl sa, goods o, gdinput i, vendorh v, store sh Where sh.code = t.storeCode
    And sa.storeGid = sh.gid And i.code = t.gdCode and i.gid = o.gid And o.gid = sa.GdGid And v.gid = sa.vdrgid and v.code = t.vendorCode);

背景说明:

  • 该SQL目的是校验临时表TMP_GENDIRALCORD_EXCEL 中供应商是否为商品配送方案的供应商
  • v_StoreAlcSchemeDtl为配送方案明细表,大约有1100多万数据

问题分析

  • SQL导致v_StoreAlcSchemeDtl表做了全表扫描,而且是Exists 子查询
  • 相当于临时表每行数据都会全表扫描一次v_StoreAlcSchemeDtl
  • 可想而知消耗资源多么大
    在这里插入图片描述

优化思路:

  • 围绕着v_StoreAlcSchemeDtl 来改造
  • 是否可以避免使用子查询
  • 分析为什么会出现v_StoreAlcSchemeDtl 全表扫描
  • 是否没有使用合适的索引

优化结果:

  • 子查询目前是必要存在的,如果非要通过其他方式实现,可能改动成本较大,先暂不考虑
  • 全表扫描原因:
  • v_StoreAlcSchemeDtl 表关联了一堆基础表,所以导致该表需要把每条数据都进行数据关联
  • 但是实际上我们并不需要所有数据关联,而需要的仅仅是临时表中的小部分数据
  • 那么可以将这些基础表关联挪到子查询外面去
    在这里插入图片描述

优化反思:

  • 由于该SQL问题比较明显,所以没有较深去分析索引
  • 所以在写SQL时需要多注意子查询,是否可以避免
  • 注意用到的表中是否存在超大表
  • 如果非要用子查询,应该尽量保证子查询SQL消耗资源最少
  • 同时也尽量避免子查询中使用大表
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值