当前位置: 首页 > news >正文

千万级的大表,用这个条件查询并不会很卡,但是直接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权限。

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

http://www.cnnetsun.cn/news/105854.html

相关文章:

  • 【开题答辩全过程】以 基于javaweb的高校招生管理系统设计与实现为例,包含答辩的问题和答案
  • 【阿里淘天大模型面试揭秘】:17个核心问题及独家解答,助你轻松通关终面!
  • JavaScript DOM 原生部分(二):元素内容修改
  • 风能太阳能供电的路灯智能控制系统(论文+源码)
  • 没有测试用例,怎么才能确保测试全面?
  • Jmeter分布式测试必踩坑,全部帮你排雷
  • 13.常见的异常类有哪些?
  • 【Q#量子编程效率革命】:揭秘VSCode重构工具的5大核心技巧
  • 为什么你的Buildx构建总失败?一文看懂构建上下文陷阱(90%的人都忽略了)
  • 【VSCode Jupyter量子模拟内核深度解析】:掌握高效量子计算开发的5大核心技巧
  • OpenBoard输入法:安卓平台智能输入终极解决方案
  • 终极方案:如何用SUSFS4KSU模块实现完美内核级Root隐藏
  • 完整Blender插件清单:从建模到渲染的终极工具指南
  • 【VSCode量子编程效率革命】:批量提交作业的5大核心技巧与实战指南
  • 2026破局:以营销自动化成熟度Macom模型为鞍,驰骋增长新赛道!
  • RookieAI_yolov8:基于YOLOv8的计算机视觉辅助系统技术解析
  • 网络安全专业全方位解析,这个专业能学明白,就业绝对是王者。从零基础入门到高薪就业,收藏这篇就够了!
  • 【量子编程进阶之路】:为什么顶级工程师都在用VSCode运行QML模型?
  • 32、打造家庭与小型办公网络安全防护体系
  • AI智能体:完整课程(初级)
  • 震惊!大模型在AIOps中竟有6大“死穴“!小白程序员避坑必看,从工具到智能要素的蜕变之路!
  • GSE宏编译器:魔兽世界玩家的技能循环自动化神器
  • DeeplxFile:突破文件翻译限制的终极解决方案
  • 针对机械设备行业一体化项目制管理解决方案
  • 别再问资质认证怎么查了!看这家公司如何用“大模型搜索”帮客户7天拿下高新认证
  • 【量子编程数据同步新突破】:如何在Q#和Python间无缝传递变量?
  • Java后端开发常见报错及解决方案:小白与大牛的问答故事
  • DeepSeek-V3实战指南:如何精准调优batch_size解决推理性能瓶颈
  • Docker Offload资源释放难题:5个你必须掌握的优化技巧
  • 全面封禁Cursor!又一家大厂,出手了~