gpt4 book ai didi

oracle - Oracle 上的大规模 UPDATE 与 MERGE 性能

转载 作者:行者123 更新时间:2023-12-05 01:32:02 25 4
gpt4 key购买 nike

我正在尝试使用单个大量 UPDATE 语句从源表更新目标表,但执行时间比应有的长得多。

查询

UPDATE MY_DEST
SET (DEST_B, DEST_C) = (
SELECT SRC_A + SRC_B, SRC_B
FROM MY_SRC
WHERE SRC_KEY = DEST_KEY AND SRC_DATE = DEST_DATE
);

两个表都包含大约 10 到 1300 万行,它们具有匹配的主键,我们可以安全地假设目标表中的每一行在源表中都有对应的行。

表格定义

CREATE TABLE MY_SRC (
SRC_KEY VARCHAR2(50),
SRC_DATE DATE,
SRC_A NUMBER(15,2),
SRC_B NUMBER(15,2),
CONSTRAINT MY_SRC_PK PRIMARY KEY (SRC_KEY, SRC_DATE)
);

CREATE TABLE MY_DEST (
DEST_KEY VARCHAR2(50),
DEST_DATE DATE,
DEST_B NUMBER(15,2),
DEST_C NUMBER(15,2),
CONSTRAINT MY_DEST_PK PRIMARY KEY (DEST_KEY, DEST_DATE)
);

执行计划

Plan hash value: 3904754293

------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 12M| 675M| 128M (20)| 01:23:55 |
| 1 | UPDATE | MY_DEST | | | | |
| 2 | TABLE ACCESS FULL | MY_DEST | 12M| 675M| 69756 (1)| 00:00:03 |
| 3 | TABLE ACCESS BY INDEX ROWID| MY_SRC | 1 | 46 | 4 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | MY_SRC_PK | 1 | | 3 (0)| 00:00:01 |
------------------------------------------------------------------------------------------

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

4 - access("SRC_KEY"=:B1 AND "SRC_DATE"=:B2)

问题

  1. 上面的 UPDATE 查询是否无可救药地被迫使用缓慢的逐行执行计划?

  2. 我能否仅通过将其重写为 MERGE 语句来优化上述查询,例如下面的语句?

    • 替代查询,重写为 MERGE

      MERGE INTO MY_DEST
      USING (SELECT SRC_KEY, SRC_DATE, SRC_B, SRC_A + SRC_B AS SRC_C FROM MY_SRC)
      ON (DEST_KEY = SRC_KEY AND DEST_DATE = SRC_DATE)
      WHEN MATCHED THEN UPDATE SET DEST_B = SRC_B, DEST_C = SRC_C;
    • 备用执行计划

      Plan hash value: 2444580570

      ----------------------------------------------------------------------------------------
      | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
      ----------------------------------------------------------------------------------------
      | 0 | MERGE STATEMENT | | 12M| 638M| | 359K (1)| 00:00:15 |
      | 1 | MERGE | MY_DEST | | | | | |
      | 2 | VIEW | | | | | | |
      |* 3 | HASH JOIN | | 12M| 2260M| 716M| 359K (1)| 00:00:15 |
      | 4 | TABLE ACCESS FULL| MY_SRC | 12M| 568M| | 162K (1)| 00:00:07 |
      | 5 | TABLE ACCESS FULL| MY_DEST | 12M| 1695M| | 69756 (1)| 00:00:03 |
      ----------------------------------------------------------------------------------------

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

      3 - access("DEST_KEY"="SRC_KEY" AND "DEST_DATE"="SRC_DATE")
  3. 当使用 UPDATE 时,我能否获得与备用 MERGE 语句相同的良好性能?

我正在使用 Oracle 12c。

最佳答案

1) 是的,您永远不想对大型表进行(估计)1200 万次索引访问

索引 block 大部分位于磁盘上,因此您可能期望每秒访问 100 行。

即使由于缓存而每秒获得 1000 个索引访问,您仍然需要等待数小时才能处理 1200 万行。

因此执行计划 1 对于大表来说是NO GO

2) MERGE 的执行计划(具有两次全表扫描的散列连接)看起来不错,应该可以工作。

3) 是的,您可以在设置中毫无问题地使用 UPDATE 语句。您将使用 updatable join view 的功能

查询

update (
select SRC_A, SRC_B,DEST_B, DEST_C
from MY_DEST d
left outer join MY_SRC s
on d.DEST_KEY = s.SRC_KEY and d.DEST_DATE = s.SRC_DATE)
set DEST_B = SRC_A + SRC_B,
DEST_C = SRC_B
;

执行计划

---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT | | 1000K| 57M| | 6682 (1)| 00:00:01 |
| 1 | UPDATE | MY_DEST | | | | | |
|* 2 | HASH JOIN OUTER | | 1000K| 57M| 40M| 6682 (1)| 00:00:01 |
| 3 | TABLE ACCESS FULL| MY_DEST | 1000K| 28M| | 1341 (2)| 00:00:01 |
| 4 | TABLE ACCESS FULL| MY_SRC | 1000K| 28M| | 1341 (2)| 00:00:01 |
---------------------------------------------------------------------------------------

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

2 - access("D"."DEST_DATE"="S"."SRC_DATE"(+) AND
"D"."DEST_KEY"="S"."SRC_KEY"(+))

您会看到为 MERGE 创建了类似的执行计划,因此您会期待类似的性能。

最后的笔记

您还可以使用并行提示来加快速度。

别忘了您必须启用 parallel dml在你的 session 中。

ALTER SESSION ENABLE PARALLEL DML;

您的MERGE 语句不等于您的第一个UPDATE 语句。当目标表中存在主键但源表中不存在时,就会出现差异。

UPDATE 将目标列重置为 NULL,而 MERGE 让它们不变

我的UPDATE语句使用外连接,因此它的行为与您的UPDATE - 切换到内连接获取 MERGE 行为。

关于oracle - Oracle 上的大规模 UPDATE 与 MERGE 性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/65829430/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com