news 2026/4/18 12:23:32

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

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
千万级的大表,用这个条件查询并不会很卡,但是直接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 JOINMERGE 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权限。

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

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/4/18 8:18:40

好写作AI实战指南:从“写作困难户”到“高产学者”的桥梁

如果你也经历过:对着空白文档超过半小时写不出标题,文献堆积如山却理不清脉络,格式调得焦头烂额——别担心,这恰是我们搭建“桥梁”的起点。好写作AI官方网址:https://www.haoxiezuo.cn/第一步:诊断你的“写…

作者头像 李华
网站建设 2026/4/18 8:50:39

如何优化EmotiVoice输出语音的情感强度?

如何优化EmotiVoice输出语音的情感强度? 在虚拟主播的直播中,一句“谢谢你的礼物”可以是平淡致谢,也可以是激动到破音的欢呼;在游戏NPC的对话里,“小心背后!”如果是用慵懒语调说出,再紧急的信…

作者头像 李华
网站建设 2026/4/18 5:34:46

智能Agent在Docker中的网络架构设计(容器互联技术深度剖析)

第一章:智能Agent与Docker容器互联技术概述 在现代分布式系统架构中,智能Agent与Docker容器的协同工作正成为提升自动化运维与服务调度能力的关键技术。智能Agent具备环境感知、决策推理和自主执行的能力,而Docker容器则提供了轻量级、可移植…

作者头像 李华
网站建设 2026/4/18 2:40:12

基于SOA的车辆照明微服务架构设计与关键应用

摘要本文探讨了通过采用面向服务的架构(SOA)实现车辆照明系统的转型。传统的单体软件设计与分布式电子电气(E/E)架构紧密绑定,限制了系统的可扩展性并增加了开发复杂性。通过将照明功能模块化设计为微服务并部署在集中…

作者头像 李华