前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >86-给参加<SQL写法与改写培训>的学员补充一个二手案例

86-给参加<SQL写法与改写培训>的学员补充一个二手案例

作者头像
老虎刘
发布2022-06-22 18:29:00
1990
发布2022-06-22 18:29:00
举报
文章被收录于专栏:老虎刘谈oracle性能优化

最近看到一篇关于SQL改写的文章,标题为基于SQL特征的改写, 原文花了很大的篇幅做了详细的讲解, 拜读之后,感觉可能还有优化空间,我把我的分析与改写方法介绍一下, 供大家参考.

原始sql,执行时间需要2000秒:

原始SQL执行计划:

原作者对SQL做了如下改写(老虎刘注: tge_trade_info对应上面的target_big_table; tge_inct_20_bocs对应上面的source_small_table, 原作者只对原始sql做了脱敏, 改写后的sql用了业务表的原名):

原SQL改写之后的执行计划(原文就是这样,表名又被脱敏,大家按照上面我给的对应关系凑合着看):

改写后SQL执行时间大概4.5秒, 可以说是大大提升了执行效率. 从2000秒到4.5秒,客户应该非常满意了,这个案例也被作者作为典型案例分享给大家.

下面从我的优化角度来分析和优化这个SQL:

原始SQL性能差的主要问题在于tge_inct20_bocs2表的AD02_ACCT_NO字段缺少索引,如果创建了这个索引, 执行效率也会大幅提升.生产系统如果改SQL不方便, 就可以创建这个索引,也能达到优化目的,虽然执行时间可能降不到4.5秒, 但是也差不了太多.

原update改成merge之后, 执行计划由filter变成了hash join,可以不需要索引,所以执行效率大幅提升,但是还有一个重要的问题,where 部分的标量子查询还是没有去除, 说明还有优化空间, 我对原SQL的改写建议如下(去除了标量子查询):

对应的执行计划:

经过这样的改写之后, 这个SQL的效率还会得到进一步的提升. 大家可以比较一下两个merge改写的执行计划差异.

总结:

索引和SQL写法是SQL优化的关键,优化方法没有最好,只有更好.

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-04-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 老虎刘谈oracle性能优化 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档