当前位置:网站首页>86-给参加<SQL写法与改写培训>的学员补充一个二手案例

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

2022-06-22 19:11:00 老虎刘

最近看到一篇关于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优化的关键,优化方法没有最好,只有更好.

原网站

版权声明
本文为[老虎刘]所创,转载请带上原文链接,感谢
https://cloud.tencent.com/developer/article/2028244