为什么MySQL不使用索引？

Question

I have a table:

CREATE TABLE  `ais`.`last_location` (
  `timestamp` timestamp NOT NULL default '0000-00-00 00:00:00',
  `message_type` tinyint(4) NOT NULL default '0',
  `repeat_indicator` tinyint(4) NOT NULL default '0',
  `mmsi` int(11) NOT NULL default '0',
  `navigation_status` tinyint(4) NOT NULL default '0',
  `rot` tinyint(4) NOT NULL default '0',
  `sog` smallint(6) NOT NULL default '0',
  `position_accuracy` tinyint(4) NOT NULL default '0',
  `longitude` int(11) NOT NULL default '0',
  `latitude` int(11) NOT NULL default '0',
  `cog` smallint(6) NOT NULL default '0',
  `hdg` smallint(6) NOT NULL default '0',
  `time_stamp` tinyint(4) NOT NULL default '0',
  `maneuver_indicator` tinyint(4) NOT NULL default '0',
  `spare` tinyint(4) NOT NULL default '0',
  `raim_flag` tinyint(4) NOT NULL default '0',
  `sotdma_sync_state` tinyint(4) NOT NULL default '0',
  `sotdma_slot_timeout` tinyint(4) NOT NULL default '0',
  `sotdma_slot_offset` smallint(6) NOT NULL default '0',
  PRIMARY KEY  USING BTREE (`mmsi`),
  KEY `Index_2` (`timestamp`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;"

And I explain to queries:

EXPLAIN SELECT * 
FROM last_location 
WHERE `timestamp` BETWEEN '2013-01-01 12:00:00' AND '2013-06-03 11:30:00'

1, 'SIMPLE', 'last_location', 'range', 'Index_2', 'Index_2', '4', '', 83, 'Using where'

EXPLAIN SELECT * 
FROM last_location 
WHERE `timestamp` BETWEEN '2013-01-01 12:00:00' AND '2013-06-03 11:40:00'

1, 'SIMPLE', 'last_location', 'ALL', 'Index_2', '', '', '', 478, 'Using where'

Can anyone tell me the difference between searching to 11:30 and 11:40? When using 11:30 everything is looking okay I think? But when using 11:40 it does not use the index anymore?

Answer 1

Query planners reserve the right to ignore an index if statistics suggest that you'll be visiting the whole table to fetch the matching rows.

The reason is, it's cheaper to sequentially read disk pages one by one while filtering the rows you need, than it is to bounce back and forth on disk pages in the order indicated by the index.

Answer 2

Index scan takes more I/O per record (as it needs to visit the table itself in a nested loop, which is generally random access I/O) but allows to use less records (only those satisfying the sargable condition).

Table scan inevitably scans the whole table but takes much less I/O per record (it's a sequential scan over one .MYD file).

MySQL's optimizer is aware of that and may choose one or another access path depending on the selectivity of the sargable condition: more selective conditions are likely to benefit form the index scan, less selective would be more efficient with a full table scan.

This is what you are observing.

Note that the optimizer's solution may be inefficient, especially if you have some specific data distribution, I/O subsystem layout etc. You may force the index scan:

SELECT  *
FROM    last_location FORCE INDEX (Index_2)
WHERE   `timestamp` BETWEEN '2013-01-01 12:00:00' AND '2013-06-03 11:40:00'

if you believe the index is more efficient.