注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Oracle、MySQL资料及经验

.

 
 
 

日志

 
 

sql优化一例  

2016-11-23 17:19:54|  分类: 优化 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
sql优化一例
上午收到短信告警,一备库活动会话数过多,查到都是一条问题sql大量运行,由于该sql运行很慢,导致CPU 100%,为尽快让系统可用,我杀掉了该sql的若干进程,sql内容如下,去掉其中的注释符号几乎就是原始sql。

SELECT  DISTINCT fppolicyin0_.*
  FROM FP_POLICYINFO_DT   fppolicyin0_,
       CODE_AIRWAYS       tkcodeairw1_,
       /*FP_POLICY_ISSUE_DT fppolicyis2_, */ 
       CODE_AIRDROME      tkcodeaird3_,
       CODE_AIRDROME      tkcodeaird4_,
       FP_POLICY_ISSUE_DT fppolicyis5_
 WHERE fppolicyin0_.POLICY_ID = fppolicyis5_.ID
   AND 1 = 1
   AND fppolicyis5_.STATUS = '1'
   AND fppolicyin0_.CARRIER_CODE = tkcodeairw1_.ID
   /*AND fppolicyin0_.POLICY_ID = fppolicyis2_.ID */  --第二问题点
   AND (fppolicyin0_.LEVDROME = tkcodeaird3_.AIRDROMEID
       --OR fppolicyin0_.LEVDROME='*'     --关键问题点
       )
   AND (fppolicyin0_.ARVDROME = tkcodeaird4_.AIRDROMEID /*OR
       fppolicyin0_.ARVDROME = '*'*/)
   AND (fppolicyin0_.LEVCITY = 'XIY' and fppolicyin0_.ARVCITY = 'SHA' OR
       (fppolicyin0_.LEVCITY, fppolicyin0_.ARVCITY) =
       (SELECT tkcodeaird6_.CITYID, tkcodeaird7_.CITYID
           FROM CODE_AIRDROME tkcodeaird6_, CODE_AIRDROME tkcodeaird7_
          WHERE tkcodeaird6_.AIRDROMEID = 'XIY'
            and tkcodeaird7_.AIRDROMEID = 'SHA'
            and rownum = 1))
   AND (fppolicyin0_.POLICY_SOURCE IS NULL
       /*OR fppolicyin0_.POLICY_SOURCE<>'P' */
       )
   AND (
       /*fppolicyin0_.TKT_STARTDATE   IS NULL
       OR */
        fppolicyin0_.TKT_STARTDATE <= '2016-11-23')
   AND (
       /*fppolicyin0_.TKT_ENDDATE   IS NULL
       OR */
        fppolicyin0_.TKT_ENDDATE >= '2016-11-23')


我执行的步骤:
1. 看执行计划,查找是否有大表全表扫描,如果有,则尝试建索引。  发现没有全表扫描,执行计划中有bitmap操作,隐约觉得不妥,但不确定。
2. 收集这6张表(实际是4张表)的统计信息      由于是突然爆发了问题,所以我怀疑某些表的统计信息出了问题。结果收集统计信息后,问题依旧。
3. 尝试新建索引   根据查询条件,检查哪些列上可以新建索引,没发现哪个条件可以很好的建索引,尝试建了三个,发现用不上。
4. 重建索引   有段时间没重建索引了,所以怀疑索引过于稀疏,导致索引效率低下,索引重建后,效率还是一样。
5. 查看带绑定变量值的执行计划    由于备库上查不到绑定变量值,所以准确的执行计划也没法确定,于是跟开发要来绑定变量值,重新分析执行计划,带绑定变量值的sql执行一次30分钟左右,没有大表全表扫描,也没有哪部分执行计划突然变高可加索引改善。
6. sql改写   既然sql没法加索引优化,只能改写了。分别尝试注释掉一部分where条件,看sql是否变快,最终发现OR fppolicyin0_.LEVDROME='*' 注释掉后,性能提升明显,查询fppolicyin0_表中也没有等于'*'的值,于是跟开发商量是否可把该条件去掉,开发说可以。于是注释了该条件,为避免以后LEVDROME列值为'*',在fppolicyin0_表中加了个LEVDROME<>'*'的约束条件。还修改了其他一些地方,但性能提升不明显,如上面sql中注释掉的部分,发现都是可以去掉的。另外,sql中出发城市和目的城市原来是两个and条件,我给合并成一个条件了。
7. 后续优化   注释掉OR fppolicyin0_.LEVDROME='*' 后,执行时间已经从30分钟变为4秒多了,而且发现没法提升性能了,除非删除fppolicyin0_表中部分无用的数据。于是把优化方案发给了同事,其实上午他也在看这条sql,他提醒我fppolicyis2_和fppolicyis5_是重复的,可以去掉一个,由于fppolicyis5_还有其他查询条件,所以我去掉了fppolicyis2_,发现性能又提升了1秒。

最终,这条sql注释了一个完全多余的where条件和去掉了一个多余的表关联,性能从30分钟变成了3秒钟。



  评论这张
 
阅读(39)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017