3

假设我们有以下问题：

  • 给定一个包含一列的表，其中'X'包含一些从 1 到 100 的随机整数的行： 

    CREATE TABLE xtable(x) AS 
   SELECT ceil(dbms_random.value * 100) 
     FROM dual
   CONNECT BY level <= 1000000;

  • 我们必须删除重复的行，以便所有不同的整数都保留在表中。

让我们考虑下面的三种解决方案（平均执行时间和优化器计划）。

我必须补充一点，实验表明：

  • 解决方案 1 和 2 是可扩展的，并且随着每行数量步骤的线性时间增长（使用多达 1000 万行的表进行测试）
  • 解决方案 3 的指数时间增长近似于3 * exp(0.6 * N)

我们看到，对于解决方案 2 ，优化器计划给出了与实验结果无关的期望，甚至与它们相反：

  • 计划 2 和 3 中的成本和其他值几乎相同
  • 解决方案 1 和 2 的执行时间几乎相同

在这个实验中，表的收集统计数据的存在与否不会影响优化器计划和执行时间。

请解释为什么我不能相信案例 2 中的优化器计划。

是什么导致优化器忽略了线性复杂度和指数复杂度之间的明显区别？

解决方案：
1。

DELETE xtable WHERE rowid IN (
      SELECT ri from (
         SELECT rowid                                             AS ri,
                row_number() OVER(PARTITION BY x ORDER BY null) AS rn
           FROM xtable
      )
      WHERE rn > 1
)


Exe time: 14 - 16 secs

Plan:
------------------------------------------------------------------------------------
| Id  | Operation                | Name     | Rows    | Bytes    | Cost | Time     |
------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT         |          | 1000000 | 15000000 | 5119 | 00:00:01 |
|   1 |   DELETE                 | XTABLE   |         |          |      |          |
| * 2 |    HASH JOIN SEMI        |          | 1000000 | 15000000 | 5119 | 00:00:01 |
|   3 |     TABLE ACCESS FULL    | XTABLE   | 1000000 |  3000000 |  280 | 00:00:01 |
|   4 |     VIEW                 | VW_NSO_1 | 1000000 | 12000000 | 2976 | 00:00:01 |
| * 5 |      VIEW                |          | 1000000 | 25000000 | 2976 | 00:00:01 |
|   6 |       WINDOW SORT        |          | 1000000 |  3000000 | 2976 | 00:00:01 |
|   7 |        TABLE ACCESS FULL | XTABLE   | 1000000 |  3000000 |  280 | 00:00:01 |
------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
------------------------------------------
* 2 - access(ROWID="RI")
* 5 - filter("RN">1)

2.

DELETE xtable WHERE (x, rowid) NOT IN (SELECT x, min(rowid) FROM xtable GROUP BY x)

Exe time: 15 - 17 secs

Plan:
--------------------------------------------------------------------------------------
| Id | Operation                 | Name   | Rows    | Bytes   | Cost      | Time     |
--------------------------------------------------------------------------------------
|  0 | DELETE STATEMENT          |        |   50000 |  150000 | 278162850 | 03:01:06 |
|  1 |   DELETE                  | XTABLE |         |         |           |          |
|  2 |    FILTER                 |        |         |         |           |          |
|  3 |     TABLE ACCESS FULL     | XTABLE | 1000000 | 3000000 |       281 | 00:00:01 |
|  4 |     FILTER                |        |         |         |           |          |
|  5 |      SORT GROUP BY NOSORT |        | 1000000 | 3000000 |       280 | 00:00:01 |
|  6 |       TABLE ACCESS FULL   | XTABLE | 1000000 | 3000000 |       280 | 00:00:01 |
--------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
------------------------------------------
* 5 - access(INTERNAL_FUNCTION("X")=INTERNAL_FUNCTION("X") AND INTERNAL_FUNCTION(ROWID)=INTERNAL_FUNCTION("MIN(ROWID)"))
* 5 - filter(INTERNAL_FUNCTION(ROWID)=INTERNAL_FUNCTION("MIN(ROWID)") AND INTERNAL_FUNCTION("X")=INTERNAL_FUNCTION("X"))

3.

DELETE xtable a WHERE EXISTS(select 1 FROM xtable b WHERE a.x = b.x AND a.rowid < b.rowid)

Exe time: 970 - 990 sec

Plan:
----------------------------------------------------------------------------------------------
| Id  | Operation                        | Name   | Rows    | Bytes   | Cost      | Time     |
----------------------------------------------------------------------------------------------
|   0 | DELETE STATEMENT                 |        |   50000 |  300000 | 278208956 | 03:01:08 |
|   1 |   DELETE                         | XTABLE |         |         |           |          |
| * 2 |    FILTER                        |        |         |         |           |          |
|   3 |     NESTED LOOPS SEMI            |        |   50000 |  300000 | 278208956 | 03:01:08 |
|   4 |      TABLE ACCESS FULL           | XTABLE | 1000000 | 3000000 |       280 | 00:00:01 |
| * 5 |      TABLE ACCESS BY ROWID RANGE | XTABLE |   50000 |  150000 |       278 | 00:00:01 |
----------------------------------------------------------------------------------------------    
Predicate Information (identified by operation id):
------------------------------------------
* 2 - filter(:VAR2=:VAR1)
* 5 - access("B".ROWID>"A".ROWID)

计划于Oracle 12.1.0.2.0

4

2 回答 2

1

无法重现第二个计划。来了：

-------------------------------------------------------------------------------------------                                       
| Id  | Operation              | Name     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |                                       
-------------------------------------------------------------------------------------------                                       
|   0 | DELETE STATEMENT       |          |       |       |       |  3648 (100)|          |                                       
|   1 |  DELETE                | XTABLE   |       |       |       |            |          |                                       
|   2 |   MERGE JOIN ANTI NA   |          |   999K|    26M|       |  3648   (5)| 00:00:01 |                                       
|   3 |    SORT JOIN           |          |  1000K|  2929K|    22M|  3147   (3)| 00:00:01 |                                       
|   4 |     TABLE ACCESS FULL  | XTABLE   |  1000K|  2929K|       |   434   (3)| 00:00:01 |                                       
|*  5 |    SORT UNIQUE         |          |   100 |  2500 |       |   500  (16)| 00:00:01 |                                       
|   6 |     VIEW               | VW_NSO_1 |   100 |  2500 |       |   499  (16)| 00:00:01 |                                       
|   7 |      SORT GROUP BY     |          |   100 |   300 |       |   499  (16)| 00:00:01 |                                       
|   8 |       TABLE ACCESS FULL| XTABLE   |  1000K|  2929K|       |   434   (3)| 00:00:01 |                                       
-------------------------------------------------------------------------------------------
于 2016-07-05T08:34:51.620 回答
1

请解释为什么我不能相信案例 2 中的优化器计划。

你永远不应该相信优化器。CBO 是 95% 正确的，但你不知道哪 5% 是错误的。

典型的问题是使用显示的执行计划EXPLAIN PLAN 不等于执行使用的计划。（您没有说明如何获得该计划）。

如有疑问，请使用DBMS_SQLTUNE.REPORT_SQL_MONITOR进行长时间运行的查询，以查看实际计划和有问题的部分。

是什么导致优化器忽略了线性复杂度和指数复杂度之间的明显区别？

见上文，忘记计划的成本比较。处理整个表时要避免的是NESTED LOOP处理。这正是案例 3 中发生的情况。

 |  3 |     NESTED LOOPS SEMI            |       |   50000|  300000 | 278208956 | 03:01:08|
 |  4 |      TABLE ACCESS FULL           |XTABLE | 1000000| 3000000 |       280 | 00:00:01|
 |  5 |      TABLE ACCESS BY ROWID RANGE |XTABLE |   50000|  150000 |       278 | 00:00:01|

您想查看 SORT 和 HASH JOIN 这是计划 1 显示的内容。

在我看来，计划 2不会随着重复记录的数量而扩展（简单地尝试使用每行两次的表，看看你是否得到与案例 3 相同的经过时间）。优化器无法估计重复记录的数量，因此防御性地估计高数量，因此成本高。

最后但有一个评论 - 理论说你不应该观察线性行为，但充其量是O(n * log(n))。

最后一句话-您的测试数据对于删除重复数据是不现实的。通常，您有一张带有少量重复数据的大桌子。在您的设置中，除 100 之外的所有记录都是重复记录。

删除的成本决定了查找副本的成本，因此您可以观察到线性行为。

尝试

CREATE TABLE xtable(x) AS 
   SELECT ceil(dbms_random.value * 100000000) 
     FROM dual
   CONNECT BY level <= 1000000;

select count(*) total, count(*)- count(distinct x) to_be_deleted from xtable;
     TOTAL TO_BE_DELETED
---------- -------------
   1000000          5083

因此，您将删除 0.5% 的记录。现在缩放，您将观察到完全不同的模式。

于 2016-07-05T09:41:46.100 回答