关于不使用索引的问题...
时间:2011-09-02
来源:互联网
SELECT COUNT(DISTINCT(PV.P_NUM)), COUNT(PV.NOW_URL) FROM a.t_a PV WHERE PV.CREATE_TIME_INT >= 20110501 AND PV.CREATE_TIME_INT <= 20110531 AND EXISTS ( SELECT P.P_NUM FROM a.t_b P WHERE P.CONTENT_ID=3682 AND PV.P_NUM=P.P_NUM AND P.RESULT_STATUS=100 )
Execution Plan
----------------------------------------------------------
Plan hash value: 3994807272
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 181 | 5 (0)| 00:00:01 |
| 1 | SORT GROUP BY | | 1 | 181 | | |
| 2 | NESTED LOOPS SEMI | | 1 | 181 | 5 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL | t_a | 1 | 151 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| t_b | 1 | 30 | 3 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | P_CON_INDEX | 1 | | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("PV"."CREATE_TIME_INT">=20110501 AND "PV"."CREATE_TIME_INT"<=20110531)
4 - filter("P"."RESULT_STATUS"=100)
5 - access("P"."P_NUM"=SYS_OP_C2C("PV"."P_NUM") AND
"P"."CONTENT_ID"=3682)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
453573 consistent gets
4831 physical reads
0 redo size
500 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
其中t_b表中有100多w条记录
t_a表有400多w条记录
CREATE_TIME_INT 上面建了一个普通索引
我的问题 为什么 CREATE_TIME_INT 建了索引 ,oracle还是选择了全表扫描呢,CREATE_TIME_INT应该是个好索引,这个字段的值重复的不会太多
请帮忙解答一下 谢谢各位
Execution Plan
----------------------------------------------------------
Plan hash value: 3994807272
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 181 | 5 (0)| 00:00:01 |
| 1 | SORT GROUP BY | | 1 | 181 | | |
| 2 | NESTED LOOPS SEMI | | 1 | 181 | 5 (0)| 00:00:01 |
|* 3 | TABLE ACCESS FULL | t_a | 1 | 151 | 2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| t_b | 1 | 30 | 3 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | P_CON_INDEX | 1 | | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("PV"."CREATE_TIME_INT">=20110501 AND "PV"."CREATE_TIME_INT"<=20110531)
4 - filter("P"."RESULT_STATUS"=100)
5 - access("P"."P_NUM"=SYS_OP_C2C("PV"."P_NUM") AND
"P"."CONTENT_ID"=3682)
Statistics
----------------------------------------------------------
1 recursive calls
0 db block gets
453573 consistent gets
4831 physical reads
0 redo size
500 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
其中t_b表中有100多w条记录
t_a表有400多w条记录
CREATE_TIME_INT 上面建了一个普通索引
我的问题 为什么 CREATE_TIME_INT 建了索引 ,oracle还是选择了全表扫描呢,CREATE_TIME_INT应该是个好索引,这个字段的值重复的不会太多
请帮忙解答一下 谢谢各位
作者: nesta2001zhang 发布时间: 2011-09-02
TABLE ACCESS FULL | t_a | 1 | 151 | 2 (0)| 00:00:01 |
统计信息有问题啊
统计信息有问题啊
作者: dingjun123 发布时间: 2011-09-02
信息应该不会有问题 CREATE_TIME_INT这个字段是我为了能使用索引 专门创建出来的字段
作者: nesta2001zhang 发布时间: 2011-09-02
相关阅读 更多
热门阅读
-
office 2019专业增强版最新2021版激活秘钥/序列号/激活码推荐 附激活工具
阅读:74
-
如何安装mysql8.0
阅读:31
-
Word快速设置标题样式步骤详解
阅读:28
-
20+道必知必会的Vue面试题(附答案解析)
阅读:37
-
HTML如何制作表单
阅读:22
-
百词斩可以改天数吗?当然可以,4个步骤轻松修改天数!
阅读:31
-
ET文件格式和XLS格式文件之间如何转化?
阅读:24
-
react和vue的区别及优缺点是什么
阅读:121
-
支付宝人脸识别如何关闭?
阅读:21
-
腾讯微云怎么修改照片或视频备份路径?
阅读:28