EXPLAIN output suggests that my index is not being used

Question

I have set up my table with an index only on done_status(done_status = INT):

When I use:

EXPLAIN SELECT * FROM reminder  WHERE done_status=2

I get this back:

id  select_type  table     type  possible_keys  key  key_len  ref  rows  Extra
1   SIMPLE       reminder  ALL   done_status    NULL NULL     NULL 5     Using where

But when I issue this command:

EXPLAIN SELECT * FROM reminder  WHERE done_status=1

I get the following returned:

id  select_type  table     type  possible_keys  key          key_len  ref   rows  Extra
1   SIMPLE       reminder  ref   done_status    done_status  4        const 2   

The EXPLAIN shows me that it uses 5 rows, the second time 2 rows.

I don't think the index is used, if I understood it right first time it should give me 3 rows. What do I do wrong?

SHOW INDEX FROM reminder:

Table    Non_unique  Key_name     Seq_in_index  Column_name  Collation  Cardinality  Sub_part  Packed  Null  Index_type  Comment  Index_comment
reminder 1           done_status  1             done_status  A          5            NULL      NULL          BTREE

explain extended:

id  select_type  table     type  possible_keys  key          key_len  ref    rows  filtered  Extra
1   SIMPLE       reminder  ref   done_status    done_status  4        const  2     100.00

show warnings didn't show anything of interest.

Answer 1

You misunderstand what the 'rows' field is. It is the number of rows that mysql estimates it shall need to read to satisfy your query. This value can be quite inaccurate. It does not mean this is the number of rows in the result - or the actual number of rows read by mysql

Answer 2

The first execution plain is not make use of index for sure,
it could be the information_schema.statistics on the index does not catch up with the data after some write operations, or the table is not been accessed for a long time.

as explain here :- From where does the MySQL Query Optimizer read index statistics?

for the second execution plan, it seems information_schema.statistics already catch up and fix the NULL cardinality issue.

Therefore, is execute the query according to the index optimizer.

For table with small rows, it does not matter much.
But data will growth, developer should always do a check on this,
and perform the necessary analyze table when encounter cardinality is null on the index.

Answer 3

The first execution plan is not using an index.

From MySQL Reference Website:

Sometimes MySQL does not use an index, even if one is available. One circumstance under which this occurs is when the optimizer estimates that using the index would require MySQL to access a very large percentage of the rows in the table. (In this case, a table scan is likely to be much faster because it requires fewer seeks.) However, if such a query uses LIMIT to retrieve only some of the rows, MySQL uses an index anyway, because it can much more quickly find the few rows to return in the result.

If your table has only 5 rows and your query selects 3 of them, then MySQL optimizer assumes that it is more efficient to scan the whole table.