MySQL QueryOptimizer, кажется, случайно использует индекс (или нет)

Question

Я только что обнаружил следующее поведение MySQL с использованием движка InnoDB.Есть ли способ объяснить существенную разницу во времени выполнения?

Первый запрос:

   SELECT ask FROM history_time  WHERE ask> 1.5790 AND timestamp BETWEEN 1207000800290 AND        1207690900290 

Время выполнения: 0,715 с

   EXPLAIN: '1', 'SIMPLE', 'history_time', 'range', 'PRIMARY,timestamp,ask,ask_2', 'PRIMARY', '8', NULL, '3278190','Using where'

Второй запрос:

SELECT ask FROM history_time  WHERE ask> 1.5790 AND timestamp > 1207000800290

Время выполнения: 0,002 с

EXPLAIN: '1', 'SIMPLE', 'history_time', 'range', 'PRIMARY,timestamp,ask,ask_2', 'ask', '4', NULL, '5850604', 'Using where; Using index'

Третий запрос:

SELECT ask FROM history_time  WHERE ask> 1.5790 AND timestamp < 1207690900290

Время выполнения: 0,651 с

EXPLAIN: '1', 'SIMPLE', 'history_time', 'range', 'PRIMARY,timestamp,ask,ask_2', 'PRIMARY', '8', NULL, '3278190', 'Using where'

ОБЪЯСНИТЕ, что говорит мне, что только второй запрос использует индекс.Моя таблица содержит 83 млн.строк, первичный ключ является меткой времени.У меня также есть индекс на (спросить, метка времени) и один на запрос (который является избыточным и только там для целей тестирования).Почему MySQL использует индекс только для второго запроса?

Answer 1

Ваш ответ заключается в: Метод доступа к диапазону для составных индексов

Редактировать: А также вам лучше проверить это: mysql range index .есть вероятность, что оптимизатор решит, что будет быстрее использовать полное сканирование, чем индексировать.

Answer 2

Ваш запрос специально ранжируется по метке времени в качестве первичного ключа, а также по индексу Аск через ваш комментарий (аск, метка времени).Поменяйте местами ... вы хотите меньшую гранулярность в первой позиции ... (отметка времени, спросить) ... если вы не запрашиваете очень конкретное значение запроса или диапазон значений запроса.Подумайте об этом следующим образом.

Если у вас 83 миллиона строк, и вы просите что-то, что произошло в течение промежутка времени X и Y, отметка времени является вашей основой ... зачем считать что-либо ниже или большедиапазон в вопросе.Теперь вы добавляете «ask> someValue», оптимизатор может запутаться.Угадайте ... есть ли меньше значений, которые больше, чем запрашиваемое значение, или меньше значений на основе предоставленного диапазона меток времени.Если бы у вас был индекс (отметка времени, спросить), он мог бы использовать его лучше.В указанном диапазоне задайте только ask> SomeValue.

Если оптимизатор использовал текущий индекс Ask, он в основном просматривает все записи, которые превышают предоставленное значение ... затем внутри каждой из них, переходя кте, которые находятся в диапазоне отметок времени.

Теперь поменяйте местами свои критерии.Если бы вы искали конкретное значение или диапазон «спросить», то ваш текущий индекс был бы совершенно нормальным.Он будет сосредоточен только на этом диапазоне.