3

我有一个没有意义的计划的简单 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_typesort_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零件，过滤器就会消失。如果我将约束分成两个不同的约束，过滤器就会回来。

4

1 回答 1

3

一般来说，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 可能会从中受益。它真的从中受益吗？不，但甲骨文只是足够聪明地知道它可能会并且它不会（*）伤害任何东西。

(*) 在以前的版本中存在许多错误，其中这_has_ 通过破坏 CBO 估计的选择性来伤害事情。

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

SELECT * FROM dba_stat_extensions where table_name = 'LISTS';

请记住，Oracle CBO 可以自行创建统计扩展。所以可能会有你没有意识到的扩展统计数据。

于 2019-02-08T22:24:58.383 回答