使用全局临时表优化Oracle查询性能可行吗？求其他优化方案

在增量加载框架里，我们通过以下逻辑追踪源端删除行的ID：数据从ABC_VIEW视图增量加载到ABC_INCR_TAB表，当视图中有新增或修改行时，会提取并加载到增量表，再由集成框架同步到SQL Server等目标端。当源端（ABC_VIEW）存在删除行时，需要从ABC_INCR_TAB移除对应行，同时把这些删除记录存入DEL_ROWS_TAB表，用于后续清理SQL Server端的数据。

当前使用的查询如下：

INSERT INTO DEL_ROWS_TAB d
(ID)
SELECT
ID
FROM ABC_INCR_TAB t
WHERE NOT EXISTS (
SELECT 1 FROM ABC_VIEW b
WHERE t.NO_KEY = b.NO_KEY
AND t.VAL = b.VAL
AND t.LINE = b.LINE
AND t.ITEM = b.ITEM
)

现在这个查询存在性能问题：ABC_VIEW是关联4张表的复杂视图，还包含函数调用；ABC_INCR_TAB和ABC_VIEW各有约4000万条记录。我们考虑用全局临时表存储ABC_VIEW的4个键，再用于上述查询，想知道这是不是糟糕的选择？还有其他优化建议吗？

更新：执行计划信息 #

测试库中数据量约25万行时的执行计划截图如下：

注：ABC_VIEW由TAB1、TAB2、TAB3、TAB4四张表关联组成。

优化建议 #

• 全局临时表并非糟糕选择：由于ABC_VIEW是复杂视图，每次NOT EXISTS子查询都会重复解析视图、执行关联和函数调用，开销极大。把ABC_VIEW的4个键（NO_KEY、VAL、LINE、ITEM）预先提取到全局临时表（记得给这四个字段建联合索引），后续查询直接关联临时表，能避免重复执行视图的复杂逻辑，大幅降低CPU和IO开销。注意全局临时表的会话隔离特性，确保数据不会被其他会话干扰。
• 给增量表建联合索引：在ABC_INCR_TAB的NO_KEY、VAL、LINE、ITEM字段上创建联合索引，这样在做NOT EXISTS判断时，Oracle能快速定位匹配行，避免全表扫描。
• 替换NOT EXISTS为左连接+NULL判断：部分场景下，LEFT JOIN后过滤NULL的写法比NOT EXISTS更高效，可尝试改写查询：

INSERT INTO DEL_ROWS_TAB d
(ID)
SELECT t.ID
FROM ABC_INCR_TAB t
LEFT JOIN ABC_VIEW b
ON t.NO_KEY = b.NO_KEY
AND t.VAL = b.VAL
AND t.LINE = b.LINE
AND t.ITEM = b.ITEM
WHERE b.NO_KEY IS NULL

如果用了全局临时表，就把ABC_VIEW换成临时表即可。

• 优化ABC_VIEW本身：如果视图中的函数调用可以提前计算（比如用物化视图预计算结果），或者简化表关联逻辑，能从根源降低视图的执行开销。比如把视图中用到的函数逻辑改写成计算列并建索引，或者调整关联顺序减少中间结果集大小。
• 考虑分区策略：如果ABC_INCR_TAB和源表是分区表，可以按增量加载的时间分区，每次只处理对应分区的数据，缩小扫描范围。

内容的提问来源于stack exchange，提问作者Subash Basnayake