记一次生产环境存储过程优化的过程（42秒-->0.06秒）

作者：波波说运维

toutiao.com/i6680858297873990147/

概述

在拿awr报告时发现有一个存储过程效率很慢，执行要很长时间，所以在测试环境模拟，开始了我的优化之路..下面写一下我的整体优化步骤和优化后的效果。

1.存储过程如下：

通过awr报告定位到这条问题存储过程。

2.分析存储过程：

调试后分析大概需要42秒。

3、查看表数据量和定义

数量级为144万，关注微信公众号：互联网架构师，在后台回复：2T，可以获取我整理的教程，都是干货。

表定义如下：

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秒，性能获得了很大提升，到这里就剩下后面上生产测试验证的环节了，这步就忽略啦。

关微信公众号：互联网架构师，在后台回复：2T，可以获取我整理的教程，都是干货。

猜你喜欢

1、GitHub 标星 3.2w！史上最全技术人员面试手册！FackBoo发起和总结

2、如何才能成为优秀的架构师？

3、从零开始搭建创业公司后台技术栈

4、程序员一般可以从什么平台接私活？

5、37岁程序员被裁，120天没找到工作，无奈去小公司，结果懵了...

6、滴滴业务中台构建实践，首次曝光

7、不认命，从10年流水线工人，到谷歌上班的程序媛，一位湖南妹子的励志故事

8、15张图看懂瞎忙和高效的区别

9、2T架构师学习资料干货分享