Oracle 10 MERGE性能

我在Oracle 10中遇到了与MERGE非常奇怪的性能相关问题.简而言之,我有一个存储过程,它根据系统中的活动计算和存储用户排名,并且只包含一个MERGE语句：

MERGE INTO user_ranks target USING 
([complex query that returns rank_id and user_id])src ON 
(src.user_id = target.user_id)
WHEN MATCHED THEN UPDATE SET target.rank_id = src.rank_id
WHEN NOT MATCHED THEN INSERT (target.user_id,target.rank_id)
  VALUES (src.user_id,src.rank_id);

// user_ranks table structure:
CREATE TABLE user_ranks (user_id INT NOT NULL 
PRIMARY KEY USING INDEX (CREATE UNIQUE INDEX UQ_uid_uranks ON user_ranks(user_id)),rank_id INT NOT NULL,CONSTRAINT FK_uid_uranks FOREIGN KEY (user_id) REFERENCES users(id),CONSTRAINT FK_rid_uranks FOREIGN KEY(rank_id) REFERENCES ranks(id));
// no index on rank_id - intentionally,ranks table is a lookup with 
// a very few records and no delete/update allowed

用作MERGE源的子查询最多返回1条记录(user_id作为参数传递给过程).这是相当昂贵的,但执行时间是可以接受的(1-1.2秒).问题是MERGE执行时间增加到40秒以上,我不知道为什么.我尝试使用LEADING提示但没有成功.但是,如果我将语句分成两部分,第一部分 – 运行SELECT子查询并将结果(rank_id)存储到变量然后合并 – MERGE … USING(SELECT user_id,rank_id FROM DUAL)src ……一切正常.根据我的阅读,Oracle的MERGE存在已知问题,但它们主要与触发器相关(在我的情况下没有触发器).它还说MERGE比INSERT和UPDATE的组合工作慢,但我认为“正常”差异大约是5-10％,而不是30倍……

我想知道我做错了什么……谢谢你的建议.

更新
执行计划很长,在这里发布,简而言之：子查询成本本身是12737,合并 – 76305.统计输出合并：

>统计

108  recursive calls
           4  db block gets
    45630447  consistent gets
       24905  physical reads
           0  redo size
         620  bytes sent via sql*Net to client
        1183  bytes received via sql*Net from client
           2  sql*Net roundtrips to/from client
           2  sorts (memory)
           0  sorts (disk)

单子查询：

>统计

8  recursive calls
           0  db block gets
          34  consistent gets
           0  physical reads
           0  redo size
         558  bytes sent via sql*Net to client
         234  bytes received via sql*Net from client
           1  sql*Net roundtrips to/from client
           1  sorts (memory)
           0  sorts (disk)

解决方法

如果您使用 set up SQL*Plus autotrace,那么实际执行计划的哪一部分导致最大的物理和逻辑I / O并使用最多的内存只需几秒钟.

请注意,使用此方法获得的信息比简单的解释计划更精确.

解决方法

相关推荐