How does a SQL database always have physical reads when indexing? _ MySQL

How does a SQL database always have physical reads when indexing? BitsCN.com

The problem is as follows:
1 SQL> r

2 1 select count (*)

3 2 from t_edu_member_info

4 3 * where status = '1' and xs_zy = '1'

01 execution plan

02 bytes -------------------------------------------------------------------------------------------

03 0 select statement Optimizer = ALL_ROWS (Cost = 1 Card = 1 Bytes = 10)

04 1 0 SORT (AGGREGATE)

05 2 1 FILTER

06 3 2 INDEX (range scan) OF 'IND _ T_PREBM4 '(NON-UNIQUE) (Cost = 1 Card = 5 Bytes = 50)

07

08 statistics

09 ----------------------------------------------------------

10 25 recursive cballs

11 14 db block gets

12 3 consistent gets

13 1 physical reads

14 972 redo size

15 375 bytes sent via SQL * Net to client

16 372 bytes encoded ed via SQL * Net from client

17 2 SQL * Net roundtrips to/from client

18 1 sorts (memory)

19 0 sorts (disk)

20 1 rows processed

This result has been run several times, but the recursive CILS still exists. later, the trace file generated by the 10046 event contains clues. After formatting the trace file with tkprof, you can see:

1 select count (*)

2 from t_edu_member_info

3 where status = '1'

4 and xs_zy = '1'

01 call count cpu elapsed disk query current rows

02 -----------------------------------------------------------------------

03 Parse 1 0.01 0.00 0 0 0 0

04 Execute 1 0.78 0.90

BitsCN.com