Использование индекса зависит = диапазон запроса

Electric200

Всех приветствую. Столкнулся с непонятной для себя ситуацией. Есть к примеру таблица:datatime | бла | бла | блаЕсть запрос который выводит определенное количество строк в зависимости от указанного диапазона даты. Индекс установлен по столбцу datatime Запрос:
EXPLAIN SELECT SQL_NO_CACHE * from a_932 where trans_datetime BETWEEN STR_TO_DATE('2012-04-[b]20[/b] 21:00:00', '%Y-%m-%d %H:%i:%s') AND STR_TO_DATE('2012-04-25 21:00:00', '%Y-%m-%d %H:%i:%s');
Показывает что использует индекс по trans_datetime. Запрос:
EXPLAIN SELECT SQL_NO_CACHE * from a_932 where trans_datetime BETWEEN STR_TO_DATE('2012-04-[b]12[/b] 21:00:00', '%Y-%m-%d %H:%i:%s') AND STR_TO_DATE('2012-04-25 21:00:00', '%Y-%m-%d %H:%i:%s');
В первом случае EXPLAIN rows показывает количество строк указанного диапазона, во втором случае сканируется вся таблица. Вот не пойму в чем соль?
11 ответов

Electric200

сколько записей реально выбирается в каждом из случаев и сколько записей в таблице всего?


Electric200

Записей:В первом случае: 6 680Во втором: 41 203 Всего записей: 103 000Кстати FORCE INDEX (trans_datetime) вроде как заставил использовать индекс. Но снова же, проверил на других таблицах, там и FORCE INDEX (trans_datetime) даже не помогает.


Electric200

эмпирическое правило - индекс эффективен для отбора 5% от общего количества.


Electric200

Записей:В первом случае: 6 680Во втором: 41 203 Всего записей: 103 000
Ну так вот и ответ. В первом случае записей выбирается относительно мало, индекс использовать выгодно. Во втором случаем выбирается значительная (более 5%) доля записей, потому сканирование таблицы выгодней.Кстати, если сделаете ANALYZE TABLE для этой таблицы, то и в первом случае может перестать индекс использоваться.


Electric200

Спасибо милые люди! Но я тогда не пойму логики. Если оптимизатор решил не использовать индекс для данного запроса, к тому же решил сам. То почему тогда такие запросы попадают в slow_log как те которые не используют индекс? Что бы я сам проверил проверил и выбрал правильный вариант? Т.е он предполагает что может ошибаться..) И почему тогда Handler_read_rnd_next растет? как то не логично.


Electric200

То почему тогда такие запросы попадают в slow_log как те которые не используют индекс?
В slow_log запросы попадают тупо по времени их фактического выполнения. Порог настраивается.


Electric200

Это я на знаю. Настроен порог что бы медленные запросы не попадали. Так почему же такие как в примере попадают?


Electric200

Есть еще одна настройка log-queries-not-using-indexes и скорее всего она включена


Electric200

Совершенно верно! Благодарю всех за помощь.


Electric200

Это я на знаю. Настроен порог что бы медленные запросы не попадали. Так почему же такие как в примере попадают?
А вы, кстати, ничего о времени выполнения этих запросов не написали.


Electric200

1
SELECT SQL_NO_CACHE * from a_932 where trans_datetime BETWEEN STR_TO_DATE('2012-04-20 21:00:00', '%Y-%m-%d %H:%i:%s') AND STR_TO_DATE('2012-04-25 21:00:00', '%Y-%m-%d %H:%i:%s');
/* 0 rows affected, 6 688 rows found. Duration for 1 query: 0,016 sec. (+ 0,125 sec. network) */
2
SELECT SQL_NO_CACHE * from a_932 where trans_datetime BETWEEN STR_TO_DATE('2012-04-12 21:00:00', '%Y-%m-%d %H:%i:%s') AND STR_TO_DATE('2012-04-25 21:00:00', '%Y-%m-%d %H:%i:%s');
/* 0 rows affected, 41 203 rows found. Duration for 1 query: 0,125 sec. (+ 0,625 sec. network) */