1. 概述
在拿awr报告时发现有一个存储过程效率很慢，执行要很长时间，所以在测试环境模拟，开始了我的优化之路..下面写一下我的整体优化步骤和优化后的效果。
1.存储过程如下：
通过awr报告定位到这条问题存储过程。
推荐一个艿艿写的 6000+ Star 的 SpringBoot + SpringCloud + Dubbo 教程的仓库：https://github.com/YunaiV/SpringBoot-Labs
2.分析存储过程：
调试后分析大概需要42秒。
推荐一个艿艿写的 3000+ Star 的 SpringCloud Alibaba 电商开源项目的仓库：https://github.com/YunaiV/onemall
3、查看表数据量和定义
数量级为144万
表定义如下：
4、改写sql查看执行计划
因为update部分耗时比较多，所以考虑改写成select看有没走索引。
select updatetime，sendtootm from Tab_TempDriverScan where ScanWay = '1' and ShipmentNumber = v_shipmentnumber and LPN = idx.LPN and SKU = idx.SKU;
这里用了索引范围扫描，继续下一步。
5、考虑update开并行
** **
update /*+ parallel(Tab_TempDriverScan,8) */ Tab_TempDriverScan set UpdateTime = SYSDATE, SendToOTM = '1' where ScanWay = '1' and ShipmentNumber = v_shipmentnumber and LPN = idx.LPN and SKU = idx.SKU;
减少了12秒，但是还不是很理想。
6、应用bulk collect优化
改写后如下
核心脚本：
TYPE Tab_TempDriverScan_rec_type IS RECORD --声明记录类型 ( v_shipmentnumber Tab_TempDriverScan.shipmentnumber%TYPE, v_power_unit Tab_TempDriverScan.power_unit%TYPE, v_IsSend Tab_TempDriverScan.IsSend%TYPE); TYPE nested_Tab_TempDriverScan_type IS TABLE OF Tab_TempDriverScan_rec_type; --声明记录类型变量 Tab_TempDriverScan_tab nested_Tab_TempDriverScan_type; ................... LOOP fetch header1 BULK COLLECT into Tab_TempDriverScan_tab; --应用bulk collect EXIT WHEN header1%NOTFOUND; ........................
测试分析
这时候时间只需要0.06秒，性能获得了很大提升，到这里就剩下后面上生产测试验证的环节了，这步就忽略啦。
