Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: Странное поведение запроса в выборе ключа
Форумы портала PHP.SU » PHP » SQL и Архитектура БД » Странное поведение запроса в выборе ключа

Страниц (1): [1]
 

1. RomAndry - 19 Января, 2015 - 16:27:27 - перейти к сообщению
Приветствую.
Есть запрос вида
CODE (SQL):
скопировать код в буфер обмена
  1.  
  2. SELECT *
  3. FROM foo
  4. WHERE bar_id IN (218,261,219,216,217,262,254,233,235,209,234,237,236,238,197,220,239,223,208,141,136,232,139,145,144,140,138,44,126,58,120,8,117,5,119,124,113,21,30,31,33,35,36,42,94,98,72,76,77,114,111,115,101,102,108,171,172,180,154,155,185,156,196,214,204,205,206,194,131,170,224,229,277,280,282) AND....
  5.  

explain которого показывает
select_type table type possible_keys key key_len ref rows Extra
PRIMARY foo ALL key_1,key_5,key_id NULL NULL NULL 243263 Using where; Using temporary; Using filesort

Но если убрать из списка значение 5 именно его!
то получаю
select_type table type possible_keys key key_len ref rows Extra
PRIMARY foo range key_1,key_5,key_id key_1 5 NULL 25013 Using where; Using temporary; Using filesort

Почему так происходит?
Спасибо
2. LIME - 19 Января, 2015 - 16:41:34 - перейти к сообщению
на другой машине/версии?

"Вы пробовали выключить и включить компьютер?")))
3. Мелкий - 19 Января, 2015 - 16:54:50 - перейти к сообщению
Оптимизатор посчитал, что линейный fullscan по таблице будет дешевле, чем случайные чтения по ключу.
Сколько там этих пятых значений в таблице? Не помню пороговую величину, но если оптимизатор считает, что по индексу придётся читать много данных относительно всего объёма таблицы, то этот индекс использоваться не будет.

А может просто тупит оптимизатор, это всё-таки довольно тупая штука. Можно дополнительно указать подсказки: http://dev[dot]mysql[dot]com/doc/refman/[dot][dot][dot]index-hints[dot]html
4. RomAndry - 19 Января, 2015 - 16:57:55 - перейти к сообщению
Спасибо, да USE KEY ... как бы снимает вопрос, но почему именно 5?
Меняю его на другИЕ значениЯ (кол-во остается тоже) и все работает.
(Добавление)
LIME пишет:
на другой машине/версии?

таже фигня! (с) =)
5. LIME - 19 Января, 2015 - 17:04:27 - перейти к сообщению
вижу что тип обхода дерева индексов сменился на range
может ты ошибся и наоборот диапазон перечисленных значений стал без "дыр"?
6. RomAndry - 19 Января, 2015 - 17:11:39 - перейти к сообщению
Ты имеешь ввиду, что нет записи с bar_id = 5 ?
Есть такая запись, я проверял
7. LIME - 19 Января, 2015 - 17:23:13 - перейти к сообщению
Нет
обрати внимание во втором случае range
меня это больше удивляет чем отказ от индекса в первом
что там дальше по запросу?
может 5 влиять?
8. RomAndry - 19 Января, 2015 - 17:31:19 - перейти к сообщению
ты имеешь ввиду, что дальнейшая выборка, к примеру по дате, не выбирает записи относящиеся к bar_id = 5 ?
9. Мелкий - 19 Января, 2015 - 17:38:46 - перейти к сообщению
LIME пишет:
обрати внимание во втором случае range
меня это больше удивляет чем отказ от индекса в первом

Наоборот.
http://dev[dot]mysql[dot]com/doc/refman/[dot][dot][dot]plain-join-types
Именно потому что используется индекс это и есть range-запрос.
10. LIME - 19 Января, 2015 - 17:57:43 - перейти к сообщению
Так это индекс не по перечисленным значениям
они не range
(Добавление)
RomAndry хз...посмотри как это может быть связано
(Добавление)
Может отсутствие 5 убирает дальше по запросу какое-то значение выбивающееся из сплошного диапазона
убрали 5 убрали и то значение
и диапазон заработал
что-то типа того

 

Powered by ExBB FM 1.0 RC1