Еще важно помнить, что по умолчанию MySQL не синхронизирует бинарный лог с диском для каждой операции. Т.е. если машина упала, то с большой долей вероятности у вас будут разные данные в базе и в логах (бинарных). Проблему можно решить установкой параметра sync_binlog=1. Это значить, что MySQL будет синхронизировать лог с диском для каждой операции (если поставить 5, то для каждые 5 операций). Естественно, это отразиться на производительности, но это уже другая история.
В этом случае действительно будет использовано преимущество кластерного ключа, так как вся таблица будет упорядочена в первую очередь по дате и запрос будет сканировать индекс в одном «направлении». Я протестировал на таблице с 500k записей, если все нужные страницы находятся в памяти, разница в скорости не очень заметна, но если большинство страниц должно быть считано с диска, то запрос использующий новый первичный ключ отрабатывает примерно в 2.5 раза быстрее использующего просто индекс по дате. У меня получились следующие цифры:
Использует новый первичный ключ, сканирует около 230732 строк — 0.6 секунд
Использует индекс по дате — 1.7 секунд
Но если периоды, по которым нужно собирать данные фиксированы, то агрегированные таблицы — то, что нужно.
Использует новый первичный ключ, сканирует около 230732 строк — 0.6 секунд
Использует индекс по дате — 1.7 секунд
Но если периоды, по которым нужно собирать данные фиксированы, то агрегированные таблицы — то, что нужно.