update 强制 NEST_LOOP NL 的理解,被驱动表 inner table

PURPOSE

This document suggests methods of processing update statements that contain subqueries so that the query drives off the subquery (i.e. it examines the subquery first before it looks at the table to be updated). This can have advantages when the subquery contains information that would allow indexes to be used on the updated table that would otherwise be unavailable. Note that the use of the techniques illustrated here are not restricted to updates but can be modified to affect many other queries.

DETAILS

Update with subquery not using index on updated table

Consider the following update:

UPDATE emp e

SET e.empno = e.empno

WHERE e.deptno in (SELECT d.deptno FROM dept d)

/

If there is an index on e.deptno then it is possible that this may be a good access path for emp. An index lookup can only be used if there is a value provided to lookup with (unless the whole index is scanned which is typically not cost effective). In this case a lookup can only be achieved if rows have already been retrieved from dept to drive the index lookup on emp. So to perform the index lookup on emp the query needs to access dept before it accesses emp. However it is likely that the plan chosen by default for this query will look something like:

Execution Plan

0 UPDATE STATEMENT Optimizer=CHOOSE (Cost=6 Card=1 Bytes=52)

1 0 HASH JOIN (Cost=6 Card=1 Bytes=52)

2 1 TABLE ACCESS (FULL) OF 'EMP' (Cost=1 Card=14 Bytes=546)

3 1 VIEW (Cost=4 Card=21 Bytes=273)

4 3 SORT (UNIQUE)

5 4 TABLE ACCESS (FULL) OF 'DEPT' (Cost=1 Card=21 Bytes=273)

In other words it looks at emp first as opposed to dept and so does not use the index since the indexed column does not have a value to lookup with.

The optimizer does consider driving the table from both emp & dept but since it does the evaluation on a cost basis it may choose to do the query in the order that you do not want. So how can the optimizer be forced to use the subquery to drive the update?

With a select, an ordered hint could be used together with modifications to the from clause to achieve the required join order. However, an update does not have a from clause so an ordered hint cannot be used in the same way.

How to get it to use an index:

The query can be forced in to a Nested Loop join with an ORDERED and a USE_NL hint:

SQL> UPDATE /*+ ORDERED USE_NL(E) INDEX(E) */ emp e

SET e.empno = e.empno

WHERE e.deptno in (SELECT d.deptno FROM dept d)

/

15 rows updated.

Execution Plan

0 UPDATE STATEMENT Optimizer=CHOOSE (Cost=46 Card=1 Bytes=52)

1 0 NESTED LOOPS (Cost=46 Card=1 Bytes=52)

2 1 VIEW (Cost=4 Card=21 Bytes=273)

3 2 SORT (UNIQUE)

4 3 TABLE ACCESS (FULL) OF 'DEPT' (Cost=1 Card=21 Bytes=273)

5 1 INDEX (RANGE SCAN) OF 'E_DNO' (NON-UNIQUE)

Notice that the USE_NL hint specifies the inner table E (emp). Since the hint has indicated that emp should be the inner table, this leaves Dept as the outer table. Since dept is the outer table it is accessed first (before emp) and so values retrieved from dept can be used to lookup in the E_DNO index.

USE_NL 两个一起也是可以的。

Alternative solutions

  • Use PLSQL. Use the select from dept as the driving cursor for the update. 这种肯定量大就不是高效的。
  • It may also be possible to create a view on both tables and update the view. However there are numerous restrictions with using this method. 直接update 两张表
  • merge 考虑一下
相关推荐
2401_8979300620 小时前
使用Docker轻松部署Neo4j图数据库
数据库·docker·neo4j
诗句藏于尽头21 小时前
Django模型与数据库表映射的两种方式
数据库·python·django
寻星探路21 小时前
数据库造神计划第六天---增删改查(CRUD)(2)
java·大数据·数据库
盖世英雄酱581361 天前
Read timed out问题 排查
java·数据库·后端
云动雨颤1 天前
Spring Boot配置优化:Tomcat+数据库+缓存+日志,全场景教程
数据库·spring boot·tomcat
RestCloud1 天前
Kafka实时数据管道:ETL在流式处理中的应用
数据库·kafka·api
懒虫虫~1 天前
通过内存去重替换SQL中distinct,优化SQL查询效率
java·sql·慢sql治理
逛逛GitHub1 天前
1 个神级智能问数工具,刚开源就 1500 Star 了。
sql·github
寻星探路1 天前
数据库造神计划第九天---增删改查(CRUD)(5)
数据库