我有一个观点，如果我选择这样：
select * from view where date = '17-sep-10'
它会在几秒钟内返回。
如果我使用动态日期：
select *
from view
where date = to_date((select current_business_date
from v_business_day),
'mm/dd/yyyy')
它在20分钟后返回。
为什么硬编码会如此提高性能呢？此外，to_date中的选择不是问题（我认为）。它在运行时几乎立即返回。
以下是该视图的说明：
JAID_OWNER@algoja1p> desc v_positions_rm_base
Name Null? Type
----------------------------------------- -------- ----------------------------
RUN_KEY NOT NULL NUMBER(10)
POSITION_KEY NOT NULL NUMBER(10)
POSITIONS VARCHAR2(50)
INSTRUMENT_ID VARCHAR2(151)
BUSINESS_DATE NOT NULL DATE
PROCESSING_DATE DATE
PROCESSING_STATUS_KEY NOT NULL NUMBER(10)
这是我硬编码日期的解释计划。我更改了查询以对硬编码值执行to_date，因此它是一致的..
explain plan for select * from v_positions_rm_base where business_date = to_date('09/17/2010', 'mm/dd/yyyy')
-----------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 518 | 1003K| 1679 (2)| 00:00:21 |
|* 1 | FILTER | | | | | |
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN RIGHT OUTER | | 10360 | 19M| 1651 (2)| 00:00:20 |
| 4 | INDEX FAST FULL SCAN | RM_SRC_ACCT_UDX | 601 | 7212 | 2 (0)| 00:00:01 |
| 5 | VIEW | | 10360 | 19M| 1648 (2)| 00:00:20 |
|* 6 | HASH JOIN RIGHT OUTER | | 10360 | 20M| 1648 (2)| 00:00:20 |
| 7 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 1 | 96 | 9 (12)| 00:00:01 |
| 8 | HASH GROUP BY | | 1 | 51 | 9 (12)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 3 | 153 | 8 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | CODE_TRANSLATION_IDX3 | 3 | | 7 (0)| 00:00:01 |
|* 11 | HASH JOIN RIGHT OUTER | | 10360 | 19M| 1638 (2)| 00:00:20 |
| 12 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 1 | 96 | 9 (12)| 00:00:01 |
| 13 | HASH GROUP BY | | 1 | 51 | 9 (12)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 3 | 153 | 8 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | CODE_TRANSLATION_IDX3 | 3 | | 7 (0)| 00:00:01 |
|* 16 | HASH JOIN RIGHT OUTER | | 10360 | 18M| 1629 (2)| 00:00:20 |
| 17 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 404 | 42420 | 12 (9)| 00:00:01 |
| 18 | HASH GROUP BY | | 404 | 20604 | 12 (9)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 404 | 20604 | 11 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 404 | | 3 (0)| 00:00:01 |
|* 21 | HASH JOIN RIGHT OUTER | | 10360 | 17M| 1616 (2)| 00:00:20 |
| 22 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 404 | 42420 | 12 (9)| 00:00:01 |
| 23 | HASH GROUP BY | | 404 | 20604 | 12 (9)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 404 | 20604 | 11 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 404 | | 3 (0)| 00:00:01 |
|* 26 | HASH JOIN RIGHT OUTER | | 10360 | 16M| 1603 (2)| 00:00:20 |
| 27 | TABLE ACCESS FULL | SOURCE_SYSTEM | 68 | 748 | 3 (0)| 00:00:01 |
|* 28 | HASH JOIN RIGHT OUTER | | 10360 | 16M| 1599 (2)| 00:00:20 |
| 29 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 1 | 51 | 2 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 1 | | 1 (0)| 00:00:01 |
| 31 | VIEW | | 10360 | 16M| 1597 (2)| 00:00:20 |
|* 32 | HASH JOIN RIGHT OUTER | | 10360 | 7527K| 1597 (2)| 00:00:20 |
| 33 | TABLE ACCESS BY INDEX ROWID | PARAMETER_CONTROL | 1 | 38 | 2 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | | 1 (0)| 00:00:01 |
|* 35 | HASH JOIN RIGHT OUTER | | 10360 | 7142K| 1594 (2)| 00:00:20 |
| 36 | VIEW | V_ENTITY_FLAT | 1742 | 282K| 35 (9)| 00:00:01 |
|* 37 | HASH JOIN RIGHT OUTER | | 1742 | 229K| 35 (9)| 00:00:01 |
| 38 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 40066 | 6 (0)| 00:00:01 |
|* 39 | HASH JOIN RIGHT OUTER | | 1742 | 190K| 28 (8)| 00:00:01 |
| 40 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 47034 | 6 (0)| 00:00:01 |
|* 41 | HASH JOIN RIGHT OUTER | | 1742 | 144K| 21 (5)| 00:00:01 |
| 42 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 47034 | 6 (0)| 00:00:01 |
|* 43 | HASH JOIN RIGHT OUTER | | 1742 | 98K| 15 (7)| 00:00:01 |
| 44 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 47034 | 6 (0)| 00:00:01 |
| 45 | TABLE ACCESS FULL | ENTITY | 1742 | 54002 | 8 (0)| 00:00:01 |
|* 46 | HASH JOIN RIGHT OUTER | | 2432 | 1282K| 1559 (1)| 00:00:19 |
| 47 | TABLE ACCESS FULL | INSTRUMENT_ID_TYPE | 8 | 88 | 3 (0)| 00:00:01 |
|* 48 | HASH JOIN RIGHT OUTER | | 2432 | 1256K| 1555 (1)| 00:00:19 |
| 49 | TABLE ACCESS BY INDEX ROWID | PROCESSING_STATUS | 1 | 76 | 1 (0)| 00:00:01 |
|* 50 | INDEX UNIQUE SCAN | PROCESSING_STATUS_PK | 1 | | 0 (0)| 00:00:01 |
|* 51 | HASH JOIN RIGHT OUTER | | 2432 | 1075K| 1554 (1)| 00:00:19 |
|* 52 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 1 | 65 | 2 (0)| 00:00:01 |
|* 53 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 1 | | 1 (0)| 00:00:01 |
|* 54 | HASH JOIN RIGHT OUTER | | 2432 | 921K| 1551 (1)| 00:00:19 |
|* 55 | TABLE ACCESS BY INDEX ROWID| CODE_TRANSLATION | 1 | 65 | 2 (0)| 00:00:01 |
|* 56 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 1 | | 1 (0)| 00:00:01 |
|* 57 | TABLE ACCESS BY INDEX ROWID| POSITIONS | 2432 | 767K| 1549 (1)| 00:00:19 |
|* 58 | INDEX RANGE SCAN | POSITIONS_IDX_01 | 5676 | | 737 (2)| 00:00:09 |
|* 59 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | 27 | 2 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------------
以下是其他观点的解释计划：
explain plan for select * from v_positions_rm_base where business_date = to_date((select current_business_date from v_business_day), 'mm/dd/yyyy');
-------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 171K| 324M| 366K (3)| 01:13:16 |
|* 1 | FILTER | | | | | |
|* 2 | FILTER | | | | | |
|* 3 | HASH JOIN RIGHT OUTER | | 3436K| 6485M| 366K (3)| 01:13:16 |
| 4 | INDEX FAST FULL SCAN | RM_SRC_ACCT_UDX | 601 | 7212 | 2 (0)| 00:00:01 |
|* 5 | VIEW | | 3436K| 6446M| 366K (3)| 01:13:15 |
|* 6 | HASH JOIN RIGHT OUTER | | 3436K| 6806M| 366K (3)| 01:13:15 |
| 7 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 1 | 96 | 9 (12)| 00:00:01 |
| 8 | HASH GROUP BY | | 1 | 51 | 9 (12)| 00:00:01 |
| 9 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 3 | 153 | 8 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | CODE_TRANSLATION_IDX3 | 3 | | 7 (0)| 00:00:01 |
|* 11 | HASH JOIN RIGHT OUTER | | 3436K| 6492M| 366K (3)| 01:13:15 |
| 12 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 1 | 96 | 9 (12)| 00:00:01 |
| 13 | HASH GROUP BY | | 1 | 51 | 9 (12)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 3 | 153 | 8 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | CODE_TRANSLATION_IDX3 | 3 | | 7 (0)| 00:00:01 |
|* 16 | HASH JOIN RIGHT OUTER | | 3436K| 6177M| 366K (3)| 01:13:14 |
| 17 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 404 | 42420 | 12 (9)| 00:00:01 |
| 18 | HASH GROUP BY | | 404 | 20604 | 12 (9)| 00:00:01 |
| 19 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 404 | 20604 | 11 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 404 | | 3 (0)| 00:00:01 |
|* 21 | HASH JOIN RIGHT OUTER | | 3436K| 5833M| 366K (3)| 01:13:13 |
| 22 | VIEW | V_RM_FUTURES_CODE_TRANS_FLAT | 404 | 42420 | 12 (9)| 00:00:01 |
| 23 | HASH GROUP BY | | 404 | 20604 | 12 (9)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 404 | 20604 | 11 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 404 | | 3 (0)| 00:00:01 |
|* 26 | HASH JOIN RIGHT OUTER | | 3436K| 5489M| 366K (3)| 01:13:13 |
| 27 | TABLE ACCESS FULL | SOURCE_SYSTEM | 68 | 748 | 3 (0)| 00:00:01 |
|* 28 | HASH JOIN RIGHT OUTER | | 3436K| 5453M| 365K (3)| 01:13:12 |
| 29 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 1 | 51 | 2 (0)| 00:00:01 |
|* 30 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 1 | | 1 (0)| 00:00:01 |
| 31 | VIEW | | 3436K| 5286M| 365K (3)| 01:13:11 |
|* 32 | HASH JOIN RIGHT OUTER | | 3436K| 2438M| 365K (3)| 01:13:11 |
| 33 | TABLE ACCESS BY INDEX ROWID | PARAMETER_CONTROL | 1 | 38 | 2 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | | 1 (0)| 00:00:01 |
| 35 | MERGE JOIN OUTER | | 3436K| 2313M| 365K (3)| 01:13:11 |
| 36 | MERGE JOIN OUTER | | 3436K| 2064M| 365K (3)| 01:13:11 |
| 37 | SORT JOIN | | 806K| 357M| 365K (3)| 01:13:10 |
| 38 | MERGE JOIN OUTER | | 806K| 357M| 365K (3)| 01:13:10 |
| 39 | SORT JOIN | | 806K| 348M| 365K (3)| 01:13:10 |
|* 40 | HASH JOIN RIGHT OUTER | | 806K| 348M| 365K (3)| 01:13:10 |
|* 41 | TABLE ACCESS BY INDEX ROWID | CODE_TRANSLATION | 1 | 65 | 2 (0)| 00:00:01 |
|* 42 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 1 | | 1 (0)| 00:00:01 |
|* 43 | HASH JOIN RIGHT OUTER | | 806K| 298M| 365K (3)| 01:13:10 |
|* 44 | TABLE ACCESS BY INDEX ROWID| CODE_TRANSLATION | 1 | 65 | 2 (0)| 00:00:01 |
|* 45 | INDEX RANGE SCAN | CODE_TRANS_TYPE_IDX | 1 | | 1 (0)| 00:00:01 |
|* 46 | TABLE ACCESS FULL | POSITIONS | 806K| 248M| 365K (3)| 01:13:09 |
|* 47 | SORT JOIN | | 8 | 88 | 4 (25)| 00:00:01 |
| 48 | TABLE ACCESS FULL | INSTRUMENT_ID_TYPE | 8 | 88 | 3 (0)| 00:00:01 |
|* 49 | SORT JOIN | | 1742 | 282K| 36 (12)| 00:00:01 |
| 50 | VIEW | V_ENTITY_FLAT | 1742 | 282K| 35 (9)| 00:00:01 |
|* 51 | HASH JOIN RIGHT OUTER | | 1742 | 229K| 35 (9)| 00:00:01 |
| 52 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 40066 | 6 (0)| 00:00:01 |
|* 53 | HASH JOIN RIGHT OUTER | | 1742 | 190K| 28 (8)| 00:00:01 |
| 54 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 47034 | 6 (0)| 00:00:01 |
|* 55 | HASH JOIN RIGHT OUTER | | 1742 | 144K| 21 (5)| 00:00:01 |
| 56 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 47034 | 6 (0)| 00:00:01 |
|* 57 | HASH JOIN RIGHT OUTER | | 1742 | 98K| 15 (7)| 00:00:01 |
| 58 | INDEX FAST FULL SCAN | ENTITY_IDX_5 | 1742 | 47034 | 6 (0)| 00:00:01 |
| 59 | TABLE ACCESS FULL | ENTITY | 1742 | 54002 | 8 (0)| 00:00:01 |
|* 60 | SORT JOIN | | 1 | 76 | 2 (50)| 00:00:01 |
| 61 | TABLE ACCESS BY INDEX ROWID | PROCESSING_STATUS | 1 | 76 | 1 (0)| 00:00:01 |
|* 62 | INDEX UNIQUE SCAN | PROCESSING_STATUS_PK | 1 | | 0 (0)| 00:00:01 |
| 63 | MERGE JOIN CARTESIAN | | 1 | 119 | 4 (0)| 00:00:01 |
| 64 | MERGE JOIN CARTESIAN | | 1 | 81 | 3 (0)| 00:00:01 |
| 65 | MERGE JOIN CARTESIAN | | 1 | 54 | 2 (0)| 00:00:01 |
|* 66 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | 27 | 1 (0)| 00:00:01 |
| 67 | BUFFER SORT | | 1 | 27 | 1 (0)| 00:00:01 |
|* 68 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | 27 | 1 (0)| 00:00:01 |
| 69 | BUFFER SORT | | 1 | 27 | 2 (0)| 00:00:01 |
|* 70 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | 27 | 1 (0)| 00:00:01 |
| 71 | BUFFER SORT | | 1 | 38 | 3 (0)| 00:00:01 |
|* 72 | TABLE ACCESS BY INDEX ROWID | PARAMETER_CONTROL | 1 | 38 | 1 (0)| 00:00:01 |
|* 73 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX1 | 2 | | 0 (0)| 00:00:01 |
|* 74 | INDEX RANGE SCAN | PARAMETER_CONTROL_IDX3 | 1 | 27 | 2 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------------
答案 0 :(得分：3)
您有两个问题
select * from view where date = '17-sep-10'
select * from view where date = to_date(...
首先，将视图中的“日期”列与字符文字进行比较。在第二个中，它与一个日期进行比较。
如果第一个工作（并且很快），则视图中的“日期”列可能是VARCHAR2列而不是日期。您在名为current_business_date的列上执行TO_DATE这一事实表明您可能使用了错误的数据类型。
在SQL * Plus中执行DESC VIEW（或在您使用的任何工具中执行相应的操作）。
同时为两者做一个EXPLAIN PLAN select * from view where date = '17 -sep-10' 和 select * from view where date = date'2010-09-17'
答案 1 :(得分：0)
对Cagcowboy的回应
列中另一侧的to_date没有问题。
仅将COLUMN从类型中移除是一个问题。
示例：的
create table index_test
as
select object_name, created as create_dt from all_objects;
create index it_create_dt_idx on index_test (create_dt) compute statistics;
使用INDEX时没有问题，TO_DATE不在列
set autotrace on explain
select * from index_test where create_dt = to_date('17-SEP-2000', 'DD-MON-YYYY');
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1 Card=1 Bytes=26)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'INDEX_TEST' (TABLE) (Cos
t=1 Card=1 Bytes=26)
2 1 INDEX (RANGE SCAN) OF 'IT_CREATE_DT_IDX' (INDEX) (Cost=1
Card=1)
THE INDEXED COLUMN上的函数可以避免索引。
SQL> select * from index_test where trunc(create_dt) = to_date('17-SEP-2000', 'DD-MON-YYYY');
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=59 Card=3 Bytes=78
)
1 0 TABLE ACCESS (FULL) OF 'INDEX_TEST' (TABLE) (Cost=59 Card=
3 Bytes=78)
答案 2 :(得分：0)
在执行计划中，了解日期谓词的应用步骤也很有帮助。
第二个计划中的实际响应时间罪魁祸首是POSITIONS上的完整扫描。在第一个计划中，我们使用POSITIONS_IDX_01进行索引范围扫描。该索引中有哪些列？特别是，它们中的任何一个与视图中的business_date列有关吗？
我猜测v_business_day视图基于PARAMETER_CONTROL，因为这似乎在第二个计划中比第一个计划中引用的次数多。完全基于此表的第二个计划部分的估计基数为1，因此问题似乎是Oracle认为子查询可能返回多行（这与您在ROWNUM上添加条件的语句相吻合）到子查询没有改变性能）。
对评论的回复：听起来像POSITIONS.BUSINESS_DATE的统计数据是优化程序可以看到文字日期值具有高度选择性，但任意日期值可能是非常无选择。您应该查看统计信息 - 在USER_TABLES，USER_INDEXES和USER_HISTOGRAMS中 - 以查看它们是否已过期以及它们对此列的数据分布的指示。
最简单的方法可能是执行一个查询以获取当前的业务日期，然后将其作为文字插入到复杂视图的查询中。
答案 3 :(得分：0)
我要坚持下去，把它放到列数据或倾斜。
一个计划
|* 57 | TABLE ACCESS BY INDEX ROWID| POSITIONS | 2432 | 767K| 1549 (1)| 00:00:19 |
|* 58 | INDEX RANGE SCAN | POSITIONS_IDX_01 | 5676 | | 737 (2)| 00:00:09 |
另一个
|* 46 | TABLE ACCESS FULL | POSITIONS | 806K| 248M| 365K (3)| 01:13:09 |
鉴于日期'17 -Sep-2010'，Oracle假设将返回几千行。鉴于另一个非特定日期，Oracle假设一个更大的数字，如此之大，以至于日期索引是无用的。我怀疑表中的大多数行对于相同的少量日期（可能少于一百个不同的值 - 但您可以在USER_TAB_COLUMNS中查看NUM_DISTINCT）。
我说是，因为我认为统计数据可能已过时。 USER_TAB_COLUMNS上的该日期列中将有一个LOW_VALUE和HIGH_VALUE（RAW格式，而不是实际日期）。当面对高于记录的high_value的值的查询时，10g做出一些假设。如果一百个不同的值有一百万行，则每个值[在没有直方图的情况下]将假设10,000行，但是对于高于HIGH_VALUE的值，它将假设少于10,000行。它在计算中得到了所有统计数据，因此很难准确。但足够的是，数据库认为9月17日的行数量足够小，以至于值得使用索引。
因此有四件事要确定。 表中有多少行，以及日期的分布情况。 表中有多少行显示在表中，统计数据表明的是日期分布。