ORACLE实际执行计划与预估执行计划不一致性能优化案例

本文通过一次Oracle服务器巡检中发现的一条SQL语句反常现象进行深入分析,揭示了由于绑定变量类型不匹配导致执行计划从索引唯一扫描变为全表扫描的问题,并最终通过调整代码解决了该问题。

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

 

在一台ORACLE服务器上做巡检时,使用下面SQL找出DISK_READ最高的TOP SQL分析时,分析过程中,有一条SQL语句的一些反常现象,让人觉得很奇怪:

 

SELECT SQL_ID,
       SQL_TEXT, 
       DISK_READS, 
       BUFFER_GETS, 
       PARSING_SCHEMA_NAME, 
       EXECUTIONS 
FROM   V$SQLAREA 
ORDER  BY DISK_READS DESC; 

 

在SQL Developer中查看SQL的预估执行计划,发现执行计划走INDEX UNIQUE SCAN,而且IO COST其实不高。如下所示,而且执行次数也不是非常多,那么推断:很有可能这个SQL的实际执行计划跟预估的执行计划有很大偏差。

 

SELECT 
 "Extent1"."SC_NO" AS "SC_NO", 
 "Extent1"."CUSTOMER_CD" AS "CUSTOMER_CD", 
 "Extent1"."FACTORY_CD" AS "FACTORY_CD", 
 "Extent1"."REQ_USER_ID" AS "REQ_USER_ID", 
 "Extent1"."REQ_USER_GRP_ID" AS "REQ_USER_GRP_ID"
 FROM "SC_HD" "Extent1"
 WHERE ("Extent1"."SC_NO" = :p__linq__0) AND (ROWNUM <= (1) )

 

 

 

clip_image001[4]

 

 

于是根据SQL_ID生成了对应SQL的awrsqrpt报表,如下截图所示,实际执行计划确实是全表扫描,Buffer Gets与Disk Reads也很高

 

 

clip_image002[4]

 

 

在sqltrpt.sql里面分析查看该SQL时,如下所示, 可以发现其绑定变量存在隐式转换(implicit data type conversion),导致执行计划走全表扫描

 

 

clip_image003[4]

 

 

于是分析了一下绑定变量的类型,发现:P__LINQ__0的类型为NVARCHAR(32) 而实际上字段SC_NO为VARCHAR(16),所以肯定是应用程序里面给该绑定变量赋值出现了问题。

 

SQL> COL NAME FOR A32;
SQL> COL DATATYPE_STRING FOR A20;
SQL> COL VALUE_STRING FOR A20;
SQLSELECT NAME, DATATYPE_STRING, VALUE_STRING
  2   FROM v$sql_bind_capture 
  3   WHERE SQL_ID='&SQL_ID' ;
Enter value for sql_id: dhg6qnxv9c4nz
old   3:  WHERE SQL_ID='&SQL_ID'
new   3:  WHERE SQL_ID='dhg6qnxv9c4nz'
 
NAME                             DATATYPE_STRING      VALUE_STRING
-------------------------------- -------------------- --------------------
:P__LINQ__0                      NARCHAR2(32)         GS17K16005
 
SQL> 

 

后面开发人员协助检查发现,因为这个SQL是代码中Lambda表达式自动生成,后面在Property中设置了字段类型以及长度,问题解决。

 

 

            //SC_HD

            modelBuilder.Entity<SC_HD>().ToTable("SC_HD", OracleSchema);

            modelBuilder.Entity<SC_HD>().HasKey(x => x.SC_NO);

 

 

clip_image004[4]

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值