![]() |
|
案例:
发现应用程序慢,开始把目光放在检查商业逻辑的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
---------------------------------------------------------- 转贴于:计算机等级考试_考试大
[1] [2]