Oracle批量数据处理基准测试疑问：INSERT/UPDATE无增益，DELETE提升显著

核心原因拆解 #

1. DELETE逐行代码的致命逻辑错误 #

你写的逐行DELETE循环完全是错误的：

<<delete_loop>> for iDeleteRec in (select id, c1 from &svTableName) loop
     delete &svTableName where mod (id, &svDeleteWhichMod) = 0; 
end loop delete_loop;

这段代码会循环表中全部2000行，而且每一次循环都执行一次全表范围的DELETE——第一次循环就把所有mod(id,10)=0的200行删完了，剩下的1999次循环都是白跑：每次都触发SQL执行、上下文切换，但根本删不到任何行。

而批量DELETE是用forall一次性处理收集到的行，只执行一次批量删除操作，直接干掉符合条件的行，完全避免了那1999次无意义的开销，这就是DELETE性能暴涨400-500%的关键。

2. 小数据集掩盖了批量处理的优势 #

你用的2000条数据太小了，总耗时才0.02-1.1秒：

• 批量处理的核心优势是减少PL/SQL和SQL之间的上下文切换（每次切换大概几微秒），但2000次切换加起来也就几毫秒，在总耗时里占比极低，很容易被dbms_random生成随机字符串、事务提交、磁盘IO波动这些开销盖过去，导致INSERT和UPDATE的性能差异根本看不出来。
• 对INSERT和UPDATE来说，不管逐行还是批量，最终要处理的数据量、生成的undo/redo日志量都是一样的——这才是这些操作的主要开销，批量处理没法减少这部分成本，自然拉不开性能差距。

3. 你的批量代码还没用到最优写法 #

当前的INSERT/UPDATE批量实现还有优化空间：

• INSERT：直接用INSERT ... SELECT就行，比游标+bulk collect+forall更高效，减少内存拷贝和游标操作：

  insert into &svTableName (c1)
  select dbms_random.string('p',10) c1 from dual connect by level <= &svInsertHowMany;
  

• UPDATE：现在的批量代码还是先拉所有行再过滤，不如直接只拉需要更新的行，减少无用处理：

  open cUpdate for select id, c1 from &svTableName where mod(id, &svUpdateWhichMod)=0;
  fetch cUpdate bulk collect into lOBDPRec limit &svFetchRate;
  forall i in lOBDPRec.first..lOBDPRec.last
    update &svTableName set c2 = substr(c1,1,2) || ' ## ' || lOBDPRec(i).id
    where id = lOBDPRec(i).id;
  

验证和优化建议 #

• 先修逐行DELETE的bug：改成只循环需要删除的行，避免白跑：

  <<delete_loop>> for iDeleteRec in (select id from &svTableName where mod(id, &svDeleteWhichMod)=0) loop
        delete &svTableName where id = iDeleteRec.id; 
  end loop delete_loop;
  

  修复后，逐行DELETE的性能会上来，和批量的差距就正常了。
• 放大数据集测试：用10万条以上的数据测，这时上下文切换的开销会被放大，批量处理的优势就明显了。
• 单独测每个操作：把INSERT、UPDATE、DELETE分开测试，排除互相干扰，更准确看差异。

内容的提问来源于stack exchange，提问作者M. Kemp