《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 toutiao.com/i6680858297873990147 「波波说运维」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注微信公众号:【芋道源码】有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

1. 概述

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

1.存储过程如下:

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

2.分析存储过程:

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

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

文章目录
  1. 1. 1. 概述
  2. 2. 2.分析存储过程:
  3. 3. 3、查看表数据量和定义
  4. 4. 4、改写sql查看执行计划
  5. 5. 5、考虑update开并行
  6. 6. 6、应用bulk collect优化