用一个案例讲解应用程序越来越慢的原因
|
源代码网整理以下这篇论坛文章(赛迪网技术社区)主要介绍了一个导致应用程序越来越慢的的实际案例，详细内容请参考下文： 源代码网整理以下案例： 源代码网整理以下发现应用程序慢，开始把目光放在检查商业逻辑的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多学习数据库的执行机制和原理，是没有害处的。 源代码网供稿. |
