欢迎您访问我爱IT技术网,今天小编为你分享的编程技术是:【用一个案例讲解应用程序越来越慢的原因】,下面是详细的分享!
用一个案例讲解应用程序越来越慢的原因
这篇论坛文章(赛迪网技术社区)主要介绍了一个导致应用程序越来越慢的的实际案例,详细内容请参考下文:
案例:
发现应用程序慢,开始把目光放在检查商业逻辑的SQL上面,觉得没什么问题,但是执行时间大大超出我的预期。
后来询问开发人员,原来最初会取工单表里面的最近工单时间,最早工单时间来做对比。
根据经验,对索引字段做MAX或者MIN是很快的,因为索引是有序,优化器直接到索引头或者尾部去取rowid就可以了。
但是打开程序一看,SQLpreparement里面的句子是这样的:
select min(billtime),MAX(billtime) from billcontent
觉得有问题了,一看执行计划,恍然大悟:
Execution Plan
----------------------------------------------------------
Plan hash value: 1499044795
----------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 5126 (3)| 00:01:02 | | |
| 1 | SORT AGGREGATE | | 1 | 8 | | | | |
| 2 | PARTITION RANGE SINGLE| | 7653K| 58M| 5126 (3)| 00:01:02 | 1 | 1 |
| 3 | PARTITION LIST ALL | | 7653K| 58M| 5126 (3)| 00:01:02 | 1 | 21 |
| 4 | INDEX FAST FULL SCAN| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 5126 (3)| 00:01:02 | 1 | 21 |
------------------------------------------------------------
Statistics
----------------------------------------------------------
26745 consistent gets
是INDEX FAST FULL SCAN,26745 个一致读,5126 的Cost,大概查了一下,该索引拥有27632个块,现在对索引做了完全扫描。
对于一致读和Cost的计算方法,这里暂不多述。
只查一个极限值话:
select min(billtime) from billcontent;
Execution Plan
----------------------------------------------------------
Plan hash value: 4137395070
-----------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-----------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 8 | 3 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 8 | | | | |
| 2 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |
| 3 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |
| 4 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |
--------------------------------------------------------------
Statistics
----------------------------------------------------------
42 consistent gets
计划是INDEX FULL SCAN (MIN/MAX),(MIN/MAX)表明只会访问索引的头或尾,开销大大减小,只有42个一致读和极低的Cost,正常情况只能是
这个的两倍多。
马上动手改为:
SELECT
(select min(calltime) from analyse_content ),
(select MAX(calltime) from analyse_content )
FROM dual
Execution Plan
----------------------------------------------------------
Plan hash value: 2326664376
-----------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
-----------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 2 (0)| 00:00:01 | | |
| 1 | SORT AGGREGATE | | 1 | 8 | | | | |
| 2 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |
| 3 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |
| 4 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |
| 5 | SORT AGGREGATE | | 1 | 8 | | | | |
| 6 | PARTITION RANGE SINGLE | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 1 |
| 7 | PARTITION LIST ALL | | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |
| 8 | INDEX FULL SCAN (MIN/MAX)| IDX_ANALYSE_CONTENT_2 | 7653K| 58M| 3 (0)| 00:00:01 | 1 | 21 |
| 9 | FAST DUAL | | 1 | | 2 (0)| 00:00:01 | | |
-------------------------------------------------------------
Statistics
----------------------------------------------------------
84 consistent gets
完美解决。
总结:
其实这个问题很小,这个SQL人人都会写,但是很多开发人员,在写这种SQL的时候不会去思考结果产生的过程,以实现为原则,在他们眼中数据库仍然是黑盒。在测试过程中也没有仔细观察效率,在测试表数据较少,人眼感觉不出来问题,一在生产库跑就越来越慢。
所以,无论是开发和DBA多学习数据库的执行机制和原理,是没有害处的。
以上所分享的是关于用一个案例讲解应用程序越来越慢的原因,下面是编辑为你推荐的有价值的用户互动:
相关问题:电脑速度越来越慢都可能是什么原因造成的?
答:以下可以作为查证的方法,卡的原因分析 我认为安装和卸载软件不会造成电脑卡,如果电脑卡可能是木马病毒,或开机启动项过多引起的。需要对系统进行优化并合理使用电脑。 1、建议你下载恶意软件和木马强杀工具windows清理助手查杀恶意软件和木马... >>详细
相关问题:电脑运行越来越慢,是什么原因,有什么解决办法
答:1、可能机子配置比较低,杀毒软件运行造成系统运行缓慢,甚至不能忍受。例如1G的CPU装卡巴,可能装好后根本开不了机,另外装两个杀毒软件特别影响机子速度。如果真是杀毒软件引起的就要删除那个杀毒软件,装一个对系统要求低的。无充分把握不要... >>详细
相关问题:操作系统越来越慢,怎么办?
答:清理垃圾,加大系统盘,清理掉不用的程序;要不就重装系统 >>详细
- 评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)
-
