Exadata优化误区1——SQL语句无需优化

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。
至于Exadata上的SQL语句是否需要优化,直接看看下面这个案例基本上就有答案了。以下案例来自于我的一个同事,他曾经给Exadata客户做SQL优化时记录的一个案例。

如图8.3所示,是该SQL语句优化之前的执行情况。

图8.3 SQL语句优化之前的执行情况

从具体的SQL语句文本可以看出,需要对policyno字段进行分组,然后对itemdetailname字段进行行转列操作,最终只需要取出行转列操作的前500个字符。查询出来的最终结果集插入到另外一张表中。在优化之前,这条SQL语句执行了约848秒。

如图8.4所示,是该SQL语句优化之后的执行情况。

图8.4 SQL语句优化之后的执行情况

从具体的SQL语句文本可以看出,仅仅是对行转列操作部分进行了改写,将以前的wmsys.wm_concat函数改写成了listagg函数。在SQL改写之后,这条SQL语句执行了约69秒。SQL性能立马提升了近十几倍。

我们针对这一案例继续讨论,首先在11.2.0.3版本的数据库中查看wm_concatdbms_lob.substr函数的定义,具体命令如下。

可以看到,在SQL语句优化之前,wm_conact函数会将varchar2类型的数据做完行转列操作后,转换成CLOB数据类型,之后又使用dbms_lob.substr函数将CLOB数据类型转化成varchar2类型,并取前500个字符。这种CLOB数据类型和varchar数据类型的来回转换,会导致性能变得非常差。

wm_conact函数是一个undocument函数,所谓undocument函数,也即这种函数还不够稳定,后期可能存在比较大的变化,不建议用户使用这种函数。比如wm_conact函数在11.2.0.4版本中已经被废弃,这种函数的使用会给数据库版本升级带来非常大的隐患,可以想象一下,如果应用程序中大量使用了wm_conact函数,在事先不知情的情况下将数据库升级到11.2.0.4,后果是多么的恐怖。

未经允许不得转载:Oracle一体机用户组 » Exadata优化误区1——SQL语句无需优化

相关推荐