sql性能问题start with

本文分析了一条SQL查询在加载树形菜单时遇到的性能问题,查询耗时85秒,结果仅50条。通过排查发现,问题在于`WHERE`条件在递归查询后过滤,而非过滤后再递归。调整策略,先过滤再递归,查询时间降低至0.047秒。优化后的SQL语句显著提升了效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

监控数据库后台发现疑似问题SQL:
select distinct t1.gwbh, t1.gwmc, t1.p_gwbh, t1.reservation01, t1.kg_id
from t_grkh_khfa_gw t1
Where t1.lrdw_id = :1
and t1.khfa_id = :2
start with t1.p_gwbh = ‘0000’
connect by prior t1.gwbh = t1.p_gwbh
order by t1.reservation01
对应的变量值是不断变化,推测是处理逐级加载树形菜单。
但实际测试传入的变量值进行查询,发现查询速度极为差,平均高达85秒才出查询结果,而查询结果却只有<=50条,而对应的t_grkh_khfa_gw表数据只有272,880条记录.这个是有严重的性能问题,初步推断此问题可能是导致加载树形菜单出现问题的原因。
发现问题的原因为where 条件启用范围是在start with的递归查询中是将所有递归查询出的结果中进行过滤。而不是过滤出数据在进行递归查询。
而抽样不加where条件的此递归的查询数据结果集记录数高达7,593,588条,耗时85秒。
select count(1)
from t_grkh_khfa_gw t1
start with t1.p_gwbh = ‘0000’
connect by prior t1.gwbh = t1.p_gwbh
order by t1.reservation01
然后where 条件在从这700万的中间结果集中过滤出几十条数据,整个语句的性能消耗在这个700万的中间结果集的生成上,从而导致性能问题。
针对排查出的这个疑似原因,优化如下,先按照where条件过滤出所需数据,然后进行递归查询,0.047秒的毫秒级就可完成查询结果。
修正SQL如下:
select distinct t2.gwbh,
t2.gwmc,
t2.p_gwbh,
t2.gwbh,
t2.reservation01,
t2.kg_id
from (select t1.gwbh,
t1.gwmc,
t1.p_gwbh,
t1.reservation01,
t1.kg_id
from t_grkh_khfa_gw t1
Where t1.lrdw_id = :1
and t1.khfa_id = :2) t2
start with t2.p_gwbh = ‘0000’
connect by prior t2.gwbh = t2.p_gwbh
order by t2.reservation01

Distinct:去重

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值