Выполнение запроса SQL на индексированной ключ против первичного ключа

Question

У меня есть MySQL InnoDB таблицы -

create table data (
    `sha256` CHAR(64) NOT NULL, 
    'created` TIMESTAMP DEFAULT CURRENT_TIMESTAMP, 
    <some other fields> 
    PRIMARY KEY (`sha256`), 
) 

Один из самых медленных запросов в mysqld_slow_query является

select * from data where created between "2013-02-01" and "2013-03-01"; 

Для того, чтобы улучшить выполнение этот запрос у меня есть два параметра:

вариант 1: добавить индекс создан

Вариант 2: Сделать ('created', 'sha256') первичный ключ и добавить индекс на sha256.

Мысль здесь состоит в том, что, когда мы выбираем большое количество строк, например данные, собранные за месяц, я хотел бы уменьшить количество блоков B-дерева, к которым обращаются. Если мы получим доступ к этим записям с помощью индекса (вариант 1), мы все равно можем получить доступ к другому блоку для каждой записи. Вместо этого, если мы сохраним записи, отсортированные по временной отметке в качестве основного/кластерного ключа (опция 2), мы найдем большое количество записей в одном блоке B-дерева, и это уменьшит чтение диска.

Но по какой-то причине, в то время как Вариант 1 повышает производительность, Вариант 2 не улучшает его. Любые идеи, почему? И любые другие предложения? Заранее спасибо.

Answer 1

InnoDB особенно чувствителен к основным основным ключам, поскольку использует кластерные первичные индексы, а CHAR(64) делает для очень большого первичного ключа. Я бы предположил, что вы добавите столбец id AUTOINCREMENT в качестве первичного ключа и дадите sha256 уникальный индекс. Те, которые наряду с индексом на created должны помочь в производительности. Look-ups на sha256 будет немного медленнее, но все остальное будет быстрее. Вставки также будут быстрее, так как данные никогда не будут смещены вокруг случайными значениями sha256.

Я не совсем уверен, почему один индекс был бы намного быстрее, но, вероятно, это связано с тем, что составной индекс является настолько большим, хотя он является кластеризованным индексом.