sql走索引，怎么始终有物理读？

tam509

表很小，只有200多条记录。查看执行计划，走了索引，但一直有物理读。不知道什么原因。

其他的查询都正常，就这一个sql有这个问题。

1. sql> r
   
2.   1  select count(*)
   
3.   2  from t_edu_member_info
   
4.   3* where status='1' and xs_zy='1'
   
5. 
   
6. 
   
7. 执行计划
   
8. ----------------------------------------------------------
   
9.    0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1 Card=1 Bytes=10)
   
10.    1    0   SORT (AGGREGATE)
    
11.    2    1     FILTER
    
12.    3    2       INDEX (RANGE SCAN) OF 'IND_T_PREBM4' (NON-UNIQUE) (Cos
    
13.           t=1 Card=5 Bytes=50)
    
14. 
    
15. 
    
16. 
    
17. 
    
18. 
    
19. 统计信息
    
20. ----------------------------------------------------------
    
21.          25  recursive calls
    
22.          14  db block gets
    
23.           3  consistent gets
    
24.           1  physical reads
    
25.         972  redo size
    
26.         375  bytes sent via SQL*Net to client
    
27.         372  bytes received via SQL*Net from client
    
28.           2  SQL*Net roundtrips to/from client
    
29.           1  sorts (memory)
    
30.           0  sorts (disk)
    
31.           1  rows processed

复制代码

tam509

alter table t_edu_member_info cache;
还是有物理读，这表才245条记录.

battleman

走索引和物理读有必然的联系吗？

battleman

alter table t_edu_member_info move 一下，再执行多次看看

tam509

没有必然联系。但是一般来说如果是全表扫描，那么读的数据在冷端，很容易从内存中清除，再次查询时又物理读。

我强调这个，因为这sql走索引，而且就200多条数据，为什么每次都会有物理读？

tam509

move了一下，反复执行多次。执行计划依然没变。
不明白怎么老是有物理读和1个排序、。

calmsurf

记录这么少，没有必要见索引吧

battleman

感觉执行计划不太对，把表分析一下，
set autotrace traceonly
sqlplus 下执行看看

tam509

就是用sqlplus执行的，表已分析过

lfree

1.数据缓存太小。
2.能t_edu_member_info是否是表吗？