Question

I run into an interesting problem I want to understand. I have a table:

        `id` BIGINT(20) unsigned NOT NULL AUTO_INCREMENT,
        `user_id` BIGINT(20) unsigned NOT NULL,

        `followers_count` INT(10) unsigned NOT NULL DEFAULT 0,
        `friends_count` INT(10) unsigned NOT NULL DEFAULT 0,
        `statuses_count` INT(10) unsigned NOT NULL DEFAULT 0,
        `favourites_count` INT(10) unsigned NOT NULL DEFAULT 0,
        `listed_count` INT(10) unsigned NOT NULL DEFAULT 0,

        `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

        PRIMARY KEY (`id`)

I execute the following query:

SELECT followers_count,friends_count,statuses_count,favourites_count,listed_count, UNIX_TIMESTAMP(DATE(created_at)) AS id FROM user_track WHERE created_at>=DATE_SUB(NOW(),INTERVAL 14 DAY) AND user_id=’1234567′

Now, the interesting part:

1: With the following index on that table, the query takes several minutes to complete:

INDEX user_numbers (created_at,user_id,followers_count,friends_count,statuses_count,favourites_count,listed_count)

Explain query with the above index 1:

id  select_type table       type    possible_keys   key             key_len     ref     rows    Extra
1   SIMPLE      user_track  range   user_numbers    user_numbers    12          NULL    1119318 Using where; Using index

2: However, with the following index on that table, it takes less than 200ms:

INDEX user_report (user_id,id,created_at,followers_count,friends_count,statuses_count,favourites_count,listed_count)

Explain query with the above index 2:

id  select_type table       type    possible_keys   key             key_len     ref     rows    Extra
1   SIMPLE      user_track  ref     user_report     user_report     8           const   1       Using where; Using index

By explaining the query I see that the first index causes a lot of rows to be scanned, while the second index has “ref: const” and only a few rows scanned. But I would like to understand why this happens.

Answer 1

As stated in the manual:

If the table has a multiple-column index, any leftmost prefix of the index can be used by the optimizer to find rows. For example, if you have a three-column index on (col1, col2, col3), you have indexed search capabilities on (col1), (col1, col2), and (col1, col2, col3).

MySQL cannot use the index to perform lookups if the columns do not form a leftmost prefix of the index. Suppose that you have the SELECT statements shown here:

SELECT * FROM tbl_name WHERE col1=val1;
SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;

SELECT * FROM tbl_name WHERE col2=val2;
SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;

If an index exists on (col1, col2, col3), only the first two queries use the index. The third and fourth queries do involve indexed columns, but (col2) and (col2, col3) are not leftmost prefixes of (col1, col2, col3).