执行计划与实际相差很大

显示全部楼层 · 2011-5-7 01:45:08

sql：SELECT SUM(DECODE(CANCLESTATE, 3, -1, 1) ) FROM MIS_CHECK_DATA_BACK WHERE ORDERID=:B1
设置变量在pl/sql里面的执行计划-----------------------------------------------------------------------------------------------------------
| Id| Operation
| Name
| Rows| Bytes | Cost (%CPU)| Time
|
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT
|
|
1 |
8 |
4 (0)| 00:00:01 |
| 1 |SORT AGGREGATE
|
|
1 |
8 |
|
|
| 2 | TABLE ACCESS BY INDEX ROWID
| MIS_CHECK_DATA_BACK
|
1 |
8 |
4 (0)| 00:00:01 |
|*3 |INDEX RANGE SCAN
| IDX_MIS_CHECK_DATA_BACK_N2
|
1 |
|
3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------

awrsqrpt看到的实际执行
Id

千问 · 2011-5-7 01:45:08

收集ORDERID直方图~
明显是因为CBO认为索引访问返回行数太多，如果返表 cluster_factor太大，成本过高，所以选择了 CANCLESTATE列上的索引和ORDERID列上的索引进行index and操作来替代返表操作

千问 · 2011-5-7 01:45:08

zergduan 发表于 2016-8-25 12:15
收集ORDERID直方图~
明显是因为CBO认为索引访问返回行数太多，如果返表 cluster_factor太大，成本过高 ...
orderid 上有16%值为0或null，列的总大小在一千五百万量级，请问这样如何做

千问 · 2011-5-7 01:45:08

索引列起码要设计个default值 not null约束

千问 · 2011-5-7 01:45:08

带有绑定变量的SQL，使用PL/SQL看执行计划是不准的（SQLPLUS里explain plan for的方式也是不准的）。
因为没有进行绑定变量窥探，ORACLE会按照默认的选择率进行COST计算。
当你真正执行这个sql的时候，ORACLE进行绑定变量窥探后，计算出COST，而选择不同的执行计划。

千问 · 2011-5-7 01:45:08

5楼的正解

千问 · 2011-5-7 01:45:08

select * from v$sql_bind_capturewhere sql_id='XXX'
看看实际执行时代入什么值