一个隐式转换引发的执行计划错误

最新推荐文章于 2023-04-24 21:13:31 发布
最新推荐文章于 2023-04-24 21:13:31 发布
阅读量133 收藏
点赞数

查看awr报告过程发现一个隐式转换导致的索引失效问题，做做记录

awr中语句实际消耗大40多w逻辑读

代入变量后测试很快

SQL> SELECT a.order_prod_amount, b.prod_cost_price FROM user_sess a, PR_DO_T b WHERE a.prod_id = b.prod_id AND a.order_no = '125924325287';

Elapsed: 00:00:00.00

Execution Plan
----------------------------------------------------------
Plan hash value: 4287492176

-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |             |     1 |    30 |     4   (0)| 00:00:01 |       |       |
|   1 |  NESTED LOOPS                       |             |     1 |    30 |     4   (0)| 00:00:01 |       |       |
|   2 |   TABLE ACCESS BY GLOBAL INDEX ROWID| user_sess   |     1 |    21 |     3   (0)| 00:00:01 | ROWID | ROWID |
|*  3 |    INDEX UNIQUE SCAN                | SYS_C008504 |     1 |       |     2   (0)| 00:00:01 |       |       |
|   4 |   TABLE ACCESS BY INDEX ROWID       | PR_DO_T     |  2983 | 26847 |     1   (0)| 00:00:01 |       |       |
|*  5 |    INDEX UNIQUE SCAN                | SYS_C008459 |     1 |       |     0   (0)| 00:00:01 |       |       |
-------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("A"."ORDER_NO"='125924325287')
   5 - access("A"."PROD_ID"="B"."PROD_ID")


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          7  consistent gets
          2  physical reads
          0  redo size
        489  bytes sent via SQL*Net to client
        396  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

按语句sqlid查看历史执行计划

SQL> SELECT a.order_prod_amount, b.prod_cost_price FROM user_sess a, PR_DO_T b WHERE a.prod_id = b.prod_id AND a.order_no = '871314                 



SQL> set linesize 200
SQL> select * from table(dbms_xplan.display_cursor('88f4paj5t26xb'));

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------
SQL_ID  88f4paj5t26xb, child number 0
-------------------------------------
SELECT a.order_prod_amount,b.prod_cost_price                        FROM user_sess a, PR_DO_T b
                  WHERE a.prod_id  = b.prod_id                         AND a.order_no = :"SYS_B_0"

Plan hash value: 4105848458

------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |             |       |       |   106K(100)|          |       |       |

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------
|   1 |  NESTED LOOPS                |             |     1 |    30 |   106K  (1)| 00:21:14 |       |       |
|   2 |   PARTITION RANGE ALL        |             |     1 |    21 |   106K  (1)| 00:21:14 |     1 |    53 |
|*  3 |    TABLE ACCESS FULL         | user_sess  |     1 |    21 |   106K  (1)| 00:21:14 |     1 |    53 |
|   4 |   TABLE ACCESS BY INDEX ROWID| PR_DO_T     |     1 |     9 |     1   (0)| 00:00:01 |       |       |
|*  5 |    INDEX UNIQUE SCAN         | SYS_C008459 |     1 |       |     0   (0)|          |       |       |
------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter(TO_NUMBER("A"."ORDER_NO")=:SYS_B_0)

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------------
   5 - access("A"."PROD_ID"="B"."PROD_ID")


24 rows selected.

 user_sess明显走错了执行计划，使用了全表扫描

突然想到user_sess表字段order_no为varchar2猜测为隐式转换
去掉单引号测试

SQL> SELECT a.order_prod_amount, b.prod_cost_price FROM user_sess a, PR_DO_T b WHERE a.prod_id = b.prod_id AND a.order_no = 125924325287;

Elapsed: 00:00:18.46

Execution Plan
----------------------------------------------------------
Plan hash value: 4105848458

------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |             |     1 |    30 |   106K  (1)| 00:21:14 |       |       |
|   1 |  NESTED LOOPS                |             |     1 |    30 |   106K  (1)| 00:21:14 |       |       |
|   2 |   PARTITION RANGE ALL        |             |     1 |    21 |   106K  (1)| 00:21:14 |     1 |    53 |
|*  3 |    TABLE ACCESS FULL         | user_sess  |     1 |    21 |   106K  (1)| 00:21:14 |     1 |    53 |
|   4 |   TABLE ACCESS BY INDEX ROWID| PR_DO_T     |     1 |     9 |     1   (0)| 00:00:01 |       |       |
|*  5 |    INDEX UNIQUE SCAN         | SYS_C008459 |     1 |       |     0   (0)| 00:00:01 |       |       |
------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter(TO_NUMBER("A"."ORDER_NO")=125924325287)
   5 - access("A"."PROD_ID"="B"."PROD_ID")


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     484974  consistent gets
     477021  physical reads
          0  redo size
        489  bytes sent via SQL*Net to client
        396  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

找开发人员加回蛋引号避免隐式转换后恢复

注：隐式类型转换number转换成varchar2时，索引会失效。varchar2转换为number时，索引并不失效

iteye_706
关注
Oracle查询隐式类型转换不走索引
xcylive520的专栏
02-20 1945
1. 框架 mybatis，oracle 2. 问题 昨天DBA发来邮件说有一个SQL引起CPU高负载。查看了一下SQL，根据时间条件查询，时间是有索引的，但是CPU会突然飙高。 SELECT * FROM ( SELECT t1.*,rownum as rn FROM ( SELECT count(:"SYS_B_0") as COUNT ,T.USER_ID, T.USER_N
记一次Mysql隐式转换带来的坑
Bomb
12-26 545
记一次Mysql隐式转换带来的坑1. 创建表2. **插入数据**3. **全表扫描**4. **出现Bug(隐式转换)的语句**5. **出现问题的情况**6. **为什么多了两条记录**7. 总结最后，附上生产问题语句截图 为了复现生产环境产生的Bug，造了几条数据记录： 1. 创建表 CREATE TABLE `test` ( `id` bigint(20) NOT NULL AU...
小议隐式转换引起的问题
weixin_33709609的博客
10-29 113
隐式转换（Implicit conversion） ，这个情况每个程序员都或多或少的遇到过，这里我结合实际情况简单描述下常见的问题以及如何解决并阐述下原理。 所谓隐式转换主要出现在我们T-SQL语句中的where 条件里面，我们先从原因上去看一下为什么会出现隐式转换。 出现隐式转换的情况和结果： 当SQL server遇到一个不匹配类型的表达式的时候，它有两种可能：1.使用隐式转换并能够执行...
ORACLE数据库中执行计划出现INTERNAL_FUNCTION一定是隐式转换吗？
gman344的博客
12-02 794
ORACLE数据库中，我们会使用一些SQL语句找出存在隐式转换的问题SQL，其中网上流传的一个SQL语句如下，查询V$SQL_PLAN的字段FILTER_PREDICATES中是否存在INTERNAL_FUNCTION： SELECT SQL_ID, PLAN_HASH_VALUEFROM V$SQL_PLAN XWHERE X.FILTER_PREDICATES LIKE'%INTERNAL_FUNCTION%'GROUPBY SQL_ID,...
解析MySQL隐式转换问题
09-08
隐式转换可能会导致查询结果不符合预期，从而引发数据错误或查询性能下降等问题。 在本文中，通过一个实例来说明MySQL中的隐式转换问题。首先，通过创建表`t1`并插入数据，我们可以看到，尽管`id`字段被定义为`...
SQL Server 中的数据类型隐式转换问题
09-09
在上述例子中，我们遇到了一个涉及`CASE WHEN`语句和数据类型隐式转换的问题。 首先，我们创建了一个名为`TEST`的表，包含`ID`(整数)，`GOOD_TYPE`(字符串)和`GOOD_WEIGHT`(数值)三列，并插入了一条记录。然后，...
golang error隐式转换引发panic
最新发布
07-08
以下是一个示例代码，演示了错误隐式转换引发panic的情况： ```go package main import ( "fmt" ) type MyError struct { msg string } func (e MyError) Error() string { return e.msg } func main() { ...
MySQL的隐式类型转换整理总结
12-16
例如，当使用`BETWEEN`操作符时，最好使用`CAST()`确保值被转换为正确的数据类型进行比较，以避免因隐式转换导致的错误或意外行为。 在日常开发中，应尽可能避免依赖隐式类型转换，以减少潜在的错误和不可预测的...
有趣的JavaScript隐式类型转换操作实例分析
10-15
如果其中一个是字符串，另一个是其他类型，JavaScript会尝试将非字符串转换为字符串。例如，`"2" + 3` 的结果是 `"23"`，而不是 `5`。 3. **比较运算**：在进行比较运算（如 `==` 和 `!=`）时，JavaScript会尝试将...
SqlServer & Oracle 查询执行计划中有隐式转换的sql
Hehuyi_In的博客
03-30 1863
查看执行计划中含有隐式转换的sql（在对应数据库执行） 注意以下sql都较复杂，在数据库中执行时间可能较长 -- 查询有隐式转换的语句，转换字段源及目标类型 DECLARE @dbname SYSNAME SET @dbname = QUOTENAME(DB_NAME()); WITH XMLNAMESPACES(DEFAULT 'http://schemas.microsoft....
Ｃ语言类型的隐式转换问题
weixin_34221773的博客
10-19 128
片段A： #include <stdio.h> int main(void) { unsigned short index = 0; unsigned short i = 0; for(i=0;i<index-1;i++) printf("%d\n",i); } 在for循环中index 为u_shor...
Oracle 数据库隐式数据类型转换如何实现？
百态老人的博客
04-24 550
这里 hire_date 是日期类型,而'01-JAN-2010'是一个字符类型的常量。为进行比较,Oracle 会先将'01-JAN-2010'转换为日期类型,然后再与 hire_date 比较。因此,在实际开发中,为避免隐式转换带来的意外影响,最好将变量和列声明为准确的目标数据类型,避免过度依赖隐式转换。这里 v_char 是一个字符类型,被赋值给数字类型 v_num,Oracle 会自动将字符'1234'转换为数字 1234。-- 字符转数字,v_num 的值为 1234。
隐式转换问题
u012637838的专栏
10-01 715
1.对“普通”T&的初始化必须是一个类型T的左值，
c语言隐式类型转换——小心！
cyan
12-24 610
今天查一个和RTP协议有关的bug，代码不是我写的，如果是我写很有可能也会犯这个错误。   为了对应这个问题，我先是把网上关于RTP协议的博客又大致看了一遍，然后有把出错的函数的功能简单过了一遍。 又把调试信息打印了一遍。最后基本确定是隐式类型转换的问题，不需要做什么大的改动。 因为是前人写的代码，理解和修改都得小心翼翼，怕改了引发新的bug。   错误代码:   if ((packe...
ORACLE隐式类型转换
gman344的博客
11-23 2906
隐式类型转换简介 通常ORACLE数据库存在显式类型转换（Explicit Datatype Conversion）和隐式类型转换（Implicit Datatype Conversion）两种类型转换方式。如果进行比较或运算的两个值的数据类型不同时（源数据的类型与目标数据的类型），而且此时又没有转换函数时，那么ORACLE必须将其中一个值进行类型转换，使其能够运算。这就是所谓的隐式类型转换。其中隐式类型转换是自动进行的，当然，只有在这种转换是有意义的时候，才会自动进行。 Data C...
如何解决：出现无法将类型“xx”隐式转换为"xx"的错误
热门推荐
天天开心鸭！
12-10 2万+
前言： 相信很多小伙伴在刚入门的时候遇到的问题最多的就是此类问题了吧，但是每次都会找半天才会发现问题的所在，今天就码一篇如何快速找到此类问题的原因的文章。   问题原因： &lt;一&gt;赋值时两边的值不是同一类型，并且未进行转换 &lt;二&gt;赋值时两边的值不是同一类型，转换类型错误 &lt;三&gt;窗体中某个控件的名称与赋值的名称重复   解决方法： 下面附上各种类型...
隐式转换在执行计划中对Access predicates 和Filter predicates 的影响
数据就是一切
01-28 5555
In Oracle 10g, when we see the explain plan for a SQL, then there are 2 new items that are of interest - the Access predicate and the Filter predicate.We know that depending on the predicate inf
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值