Question

我有一个简单的Oracle查询，该查询的计划没有意义。

SELECT
    u.custid AS "custid",
    l.listid AS "listid"
FROM
    users u
    INNER JOIN lists l ON u.custid = l.custid

这是自动跟踪说明告诉我的一个计划

------------------------------------------------------------------------------------------
| Id  | Operation             | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT      |          |  1468K|    29M|       | 11548   (1)| 00:00:01 |
|*  1 |  HASH JOIN            |          |  1468K|    29M|  7104K| 11548   (1)| 00:00:01 |
|   2 |   INDEX FAST FULL SCAN| USERS_PK |   404K|  2367K|       |   266   (2)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL   | LISTS    |  1416K|    20M|       |  9110   (1)| 00:00:01 |
------------------------------------------------------------------------------------------

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

   1 - access("U"."CUSTID"="L"."CUSTID")
   3 - filter(TRUNC("SORT_TYPE")>=1 AND TRUNC("SORT_TYPE")<=16)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)
   - this is an adaptive plan
   - 1 Sql Plan Directive used for this statement

与我有关的是谓词3。sort_type不会出现在查询中，也不会被索引。在我看来，sort_type根本不应该参与此查询。

对lists.sort_type的限制是：（是的，我知道我们可以让sort_type是一个整数而不是一个数字）

sort_type   NUMBER DEFAULT 2 NOT NULL,
    CONSTRAINT lists_sort_type CHECK ( sort_type BETWEEN 1 AND 16 AND TRUNC(sort_type) = sort_type )

在我看来，sort_type上的过滤器基本上是重言式。由于该限制，lists中的每一行都必须通过该过滤器。

如果我取消约束，过滤器将不再显示在计划中，并且估计的成本将下降一点。如果我重新添加约束，则计划将再次使用过滤器。一种或另一种执行速度没有显着差异。

我很担心，因为我是在一个更大，更复杂的查询中发现这个过滤器的，而该查询是我试图从几分钟的运行时间中进行优化的。

Oracle为什么要添加该过滤器，这是一个问题和/或指向另一个问题吗？

编辑：如果我将sort_type上的约束更改为没有TRUNC部分，则过滤器消失。如果将约束分为两个不同的约束，过滤器将返回。

Answer 1

通常来说，Oracle会根据您的CHECK约束来生成谓词，只要这样做就会为优化器提供更多信息以生成一个好的计划。识别何时冗余并不总是足够聪明。这是使用表名的Oracle 12c中的简短示例：

-- Create the CUSTS table
CREATE TABLE custs ( custid number not null );
CREATE INDEX custs_u1 on custs (custid);

-- Create the LISTS table
CREATE TABLE lists 
  ( listid number not null, 
    sort_type number not null, 
    custid number,
    constraint lists_c1 check ( sort_type between 1 and 16 and
          trunc(sort_type) = sort_Type )
);

-- Explain a join
EXPLAIN PLAN FOR
SELECT /*+ USE_HASH(u) */ 
       u.custid AS "custid",
       l.listid AS "listid"
FROM custs u
INNER JOIN lists l ON u.custid = l.custid;

-- Show the plan
select * from table(dbms_xplan.display);

Plan hash value: 2443150416

-------------------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 |    39 |     3   (0)| 00:00:01 |
|*  1 |  HASH JOIN         |          |     1 |    39 |     3   (0)| 00:00:01 |
|   2 |   INDEX FULL SCAN  | CUSTS_U1 |     1 |    13 |     1   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL| LISTS    |     1 |    26 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------

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

   1 - access("U"."CUSTID"="L"."CUSTID")

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

到目前为止，没有什么奇怪的。没有添加可疑谓词。

现在，让我们告诉Oracle优化器，在TRUNC(sort_type)上的数据分布可能很重要...

declare
  x varchar2(30);
begin
  x := dbms_stats.create_extended_stats ( user, 'LISTS', '(TRUNC(SORT_TYPE))');
  dbms_output.put_line('Extension name = ' || x);
end;

...，现在，让我们再次解释该查询...

-- Re-explain the same join as before
EXPLAIN PLAN FOR
SELECT /*+ USE_HASH(u) */ 
       u.custid AS "custid",
       l.listid AS "listid"
FROM custs u
INNER JOIN lists l ON u.custid = l.custid;

-- Show the new plan
select * from table(dbms_xplan.display);

Plan hash value: 2443150416

-------------------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 |    52 |     3   (0)| 00:00:01 |
|*  1 |  HASH JOIN         |          |     1 |    52 |     3   (0)| 00:00:01 |
|   2 |   INDEX FULL SCAN  | CUSTS_U1 |     1 |    13 |     1   (0)| 00:00:01 |
|*  3 |   TABLE ACCESS FULL| LISTS    |     1 |    39 |     2   (0)| 00:00:01 |
-------------------------------------------------------------------------------

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

   1 - access("U"."CUSTID"="L"."CUSTID")
   3 - filter(TRUNC("SORT_TYPE")>=1 AND TRUNC("SORT_TYPE")<=16)

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

现在，Oracle已添加谓词，因为CBO可能会从中受益。它真的从中受益吗？否，但是Oracle只是足够聪明，知道它可能而且不会伤害任何东西。

（*）在以前的版本中存在许多错误，这些错误会干扰CBO估计的选择性，从而损害工作。

扩展统计信息的存在只是Oracle认为可以从该谓词中受益的一个示例原因。要找出是否是您的情况的原因，可以在数据库中查找扩展统计信息，如下所示：

SELECT * FROM dba_stat_extensions where table_name = 'LISTS';

请记住，Oracle CBO可以自行创建统计信息扩展。因此，可能会有您没有意识到的扩展统计信息。

为什么Oracle的查询计划人员会添加一个复制约束的过滤谓词？

1 个答案: