千万级的大表，用这个条件查询并不会很卡，但是直接delete from 的话，筛选的两万行数据要半个小时以上。已经使用了分批删除，加了索引还是这样 code1 = ‘daz1‘ AND EXISTS

🔍 首先，定位“蜗牛”在哪里

在实施上图的具体方案前，我们需要先精准定位瓶颈。您已经使用了分批删除，所以我们可以聚焦于更深层次的原因。

1. 检查外键约束（最可疑的点）：您的删除条件中包含EXISTS子查询。如果lkk.rcard列上有外键引用到您要删除的主表，那么每次删除一条记录，数据库都需要去检查lkk表上这个外键约束。如果lkk表很大或rcard列上没有索引，这个检查成本会极高。您可以通过以下查询确认：

   SELECT a.table_name, a.constraint_name, a.columns, b.columns FROM user_cons_columns a, user_constraints b WHERE a.constraint_name = b.constraint_name AND b.constraint_type = 'R' AND a.table_name = 'LKK'; -- 您的子查询表名

2. 分析删除语句的执行计划：查询快不代表删除的执行计划也是最优的。对于DELETE语句，优化器可能会选择不同的计划。使用以下命令查看删除的实际执行计划：

   EXPLAIN PLAN FOR DELETE FROM your_main_table WHERE code1 = 'daz1' AND EXISTS (SELECT 1 FROM lkk l WHERE l.rcard = code9); SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

   重点关注：执行计划是否出现了低效的NESTED LOOPS​ 连接？相比之下，HASH JOIN或MERGE JOIN通常更适合处理大量数据。

3. 审视索引情况：您说已经加了索引，但需要确认索引是否被删除操作有效利用。删除操作需要维护所有相关的索引。如果表上有多个索引，特别是包含大对象的索引，维护这些索引的开销可能非常大。

🛠️ 然后，尝试针对性的“加速”方案

基于上述分析，您可以尝试以下针对性优化策略，这些策略与上面的流程图相对应。

方案一：优化执行计划与语句

如果发现执行计划不理想，可以尝试使用Hint强制优化器选择更高效的连接方式。例如，强制使用哈希连接：

DELETE /*+ USE_HASH(l) */ FROM your_main_table m WHERE code1 = 'daz1' AND EXISTS (SELECT 1 FROM lkk l WHERE l.rcard = m.code9);

同时，确保子查询表lkk的关联字段rcard上有索引。

方案二：处理外键约束

如果确认外键是瓶颈，并且业务上允许短时间的数据不一致，可以考虑在删除期间临时禁用外键约束，删除完成后再启用。

-- 禁用约束 ALTER TABLE lkk DISABLE CONSTRAINT constraint_name; -- 执行删除操作 -- 重新启用约束 ALTER TABLE lkk ENABLE CONSTRAINT constraint_name;

注意：此操作有风险，需确保在禁用约束期间没有新的不一致数据插入。

方案三：优化您的分批删除策略

您已经在分批删除了，但可以进一步优化：

• 调整批次大小：不要简单地用ROWNUM。尝试根据主键或索引列进行分批，这样可以有效利用索引，减少每批需要扫描的数据量。

  DECLARE l_min_id NUMBER; l_max_id NUMBER; l_batch_size NUMBER := 1000; -- 调整批次大小 BEGIN SELECT MIN(id), MAX(id) INTO l_min_id, l_max_id FROM your_main_table WHERE code1 = 'daz1'; FOR i IN l_min_id .. l_max_id LOOP DELETE FROM your_main_table WHERE id BETWEEN i AND i + l_batch_size - 1 AND code1 = 'daz1' AND EXISTS (SELECT 1 FROM lkk l WHERE l.rcard = code9); COMMIT; END LOOP; END;

• 在删除前暂时移除非必要索引：如果删除的数据量非常大，可以考虑先删除非关键索引，待数据删除完毕后再重建索引。这对于大数据量删除通常有奇效。

💎 终极方案：转换思路

如果上述方法效果仍不理想，或者要删除的数据占了表的很大一部分（比如超过30%），那么最有效的方法是放弃直接删除，采用“临时表”策略，也就是流程图中的终极方案。

1. 创建一个临时表，存放需要保留的数据。

   CREATE TABLE your_main_table_temp AS SELECT * FROM your_main_table WHERE NOT (code1 = 'daz1' AND EXISTS (SELECT 1 FROM lkk l WHERE l.rcard = code9));

2. 清空原表（使用TRUNCATE，因为它是DDL操作，速度极快且不产生重做日志）。

   TRUNCATE TABLE your_main_table;

3. 将临时表中的数据插回原表。

   INSERT INTO your_main_table SELECT * FROM your_main_table_temp; COMMIT;

4. 最后重建索引，并删除临时表。

✨ 一些辅助的检查与优化

• 在业务低峰期操作：大规模数据操作尽量选择在系统空闲时段进行。

• 调整数据库参数：如果可能，适当增大回滚段或临时表空间，但这需要DBA权限。

• 关注重做日志：大批量删除会产生大量重做日志，确保日志文件有足够空间和切换频率。