Oracle中delete...exists慢的主因是优化器误选驱动表或缺失索引，导致NL+全表扫描；应优先通过hint（如use_hash、leading）调整执行计划或添加索引，而非改用in。
where exists 删除语句为什么慢
Oracle 中 delete from tableA where exists (select 1 from tableB where tableA.id = tableB.id) 看似简洁，但执行计划常显示为 **NL（嵌套循环）+ 全表扫描**，尤其当 tableB 没有在关联字段上建索引时，每条 tableA 记录都会触发一次 tableB 全扫 —— 数据量稍大就卡住。
根本原因不是 exists 本身，而是优化器没选对驱动表，或缺失关键索引。别急着换写法，先看执行计划里 access 和 filter 是落在哪张表、哪个字段上。
用 /*+ use_hash */ 或 /*+ leading */ 强制改写执行路径
如果 tableB 小、tableA 大，让 tableB 做驱动表更合理；反之则反。Oracle 不总能自动判断，得手动干预：
delete from tableA where exists ( select /*+ use_hash(a b) leading(b) */ 1 from tableB b where b.id = tableA.id );
-
/*+ leading(b) */明确指定tableB为驱动表 -
/*+ use_hash(a b) */避免 NL，改用哈希连接（适合大结果集） - 注意：hint 必须写在子查询的
select后，不能写在外层delete上 - 实际生效前，用
explain plan for ...看是否被采纳；若被忽略，可能是统计信息过旧，先跑dbms_stats.gather_table_stats
exists 改成 in 可能更慢，别盲目替换
有人觉得 in 更直观，但 Oracle 对 in (subquery) 的处理在某些版本中会退化成 FILTER + SORT UNIQUE，尤其子查询返回空值或大量重复时。除非满足以下全部条件，否则不建议换：
-
tableB.id是非空且唯一（如主键或带not null约束的唯一索引） - 子查询结果集远小于
tableA，且已缓存在 PGA 中 - 你确认
in执行计划里出现了NESTED LOOPS ANTI或高效哈希反连接
更稳妥的做法是保持 exists，只加 hint 或补索引。
真正快的方案：用 with + delete returning 或分批 commit
当要删几十万行以上，单条 delete ... exists 容易锁表、占大量 undo、甚至 OOM。推荐拆成两步：
with to_del as (
select /*+ materialize */ a.rowid rid
from tableA a
where exists (
select 1 from tableB b where b.id = a.id
)
)
delete from tableA where rowid in (select rid from to_del);
-
/*+ materialize */把中间结果物化进临时段，避免多次执行子查询 - 用
rowid删除比基于业务字段快，且规避了重复值或函数索引失效问题 - 生产环境务必加
and rownum 分批，配合 <code>commit，防止事务过大
最易被忽略的是：物化 CTE 在 Oracle 12c+ 默认启用，但低版本需显式加 hint；另外，rowid 方案要求两张表都无分区裁剪干扰，否则可能漏删。
