最初由 nmgzw 发布
[B]个人认为,这个和使用不使用函数不是一个问题!
关键是数据的组织方式!
我所能理解到的就是,如果oracle优化算法认为数据基本上(我想不一定说完全)是按1,2,3。。。1000,或者相反的顺序在表里存放,那么肯定index range scan很快就能发现需要的max或min值!!!
但如果是无序的在表里存放的话,这时候index range scan (max/min),无疑是最快的,因为它每次只需要保存max/min的值在一定的范围内进行比较!!!
而且从下面的执行计划来看,走min/max的话要进行多处理一步的!!!正常情况数据按顺序组织的话,根本就不该走min/max!!!!!
[php]
SQL> select max(rn1) from test1 where rn1 like '%%'
2 ;
Execution Plan
----------------------------------------------------------
Plan hash value: 520396533
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 41 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 41 | | |
| 2 | FIRST ROW | | 20876 | 835K| 3 (0)| 00:00:01 |
|* 3 | INDEX FULL SCAN (MIN/MAX)| TEST1_RN1 | 20876 | 835K| 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("RN1" LIKE '%%')
SQL> select max(rn1) from test1 where rn1 like '2%';
Execution Plan
----------------------------------------------------------
Plan hash value: 1800614985
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 41 | 338 (1)| 00:00:05 |
| 1 | SORT AGGREGATE | | 1 | 41 | | |
|* 2 | INDEX RANGE SCAN| TEST1_RN1 | 46026 | 1842K| 338 (1)| 00:00:05 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("RN1" LIKE '2%')
filter("RN1" LIKE '2%')
[/php]
[/B]