Using filesort

[flash-vkv]

type=index не говарит что индекс неправельны, а говарит что этот индекс используется для перебора, всеже он используется чем совсем нет. Что вобшем то и требовалось. по другому помоему некак конечно если в результате uid IN(119103, 144163, 71119, 88182, 76123, 94095, 135607, 113842, 13963, 2944) всего 10 строк то думаю серверу проше их отсортировать самаму, достаточно будет индекса по uid.

 

[Апельсин]

flash-vkv, о том что индекс "неправильный" говорит то, что он не значится в списке possible keys.

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

Во всяком случае переходить на InnoDB в надежде, что это ускорит SELECTы не стоит.

 

[flash-vkv]

согласен что смена типа таблице невсегда целесообразна, думаю что случий antenne из этого числа. Но вот когда после условия uid IN(119103, 144163, 71119, 88182, 76123, 94095, 135607, 113842, 13963, 2944) результат получается в несколько тысяч строк и приэтом необходимо еше сортеровать по другому полю то уже можно задуматься.
possible keys - говарит что нет подходяших индексов.

 

[Апельсин]

flash-vkv, у него там 10 строк, а не несколько тысяч. Отсортировать 10 строк - невелика проблема.

 

[antenne]

antenne, а сколько строк в таблице вообще?

вообще - 150 тысяч

Да и еще
2 секунды выполняется - это только когда первый раз к таблице обращаешься или всегда?
Если только первый, то оно просто индексы в кэш грузит.

2 секунды - я такого пока не видел.
проблема в том, что время плавает _ от 2 до 80 миллисекунд

Понял бы, если оно было приблизительно одинаковым.. а так, слишком большой разброс

 

[flash-vkv]

а 2..80 мс это разные запросы или один итотже, те uid IN(119103, 144163, 71119, 88182, 76123, 94095, 135607, 113842, 13963, 2944) и uid IN(222222, 3333333, 44444444, 55555555) может дать совершенно разное время, и по разному могут работать индексы.

-~{}~ 22.09.06 19:47:

antenne решение какоето найдено?

 

[Апельсин]

antenne, аа .. это от 2х милисекунд .. я прочитала как 2 секунды.

Это время выполнения одного и того же запроса или схожих, но с разными значениями для uid?

Когда тестировал - это рабочий сервер (загруженый) или тестовый?

Такая разницы во времени выполнения постоянно скачет или бОльшее время требуется только при первом обращении к таблице?

 

[antenne]

Автор оригинала: flash-vkv
а 2..80 мс это разные запросы или один итотже, те uid IN(119103, 144163, 71119, 88182, 76123, 94095, 135607, 113842, 13963, 2944) и uid IN(222222, 3333333, 44444444, 55555555) может дать совершенно разное время, и по разному могут работать индексы.

запросы разные, т.е. список uid меняется, но общее кол-во всегда 10

antenne решение какоето найдено?

пока нет.. ищем причину

-~{}~ 23.09.06 12:33:

Автор оригинала: Апельсин
antenne, аа .. это от 2х милисекунд .. я прочитала как 2 секунды.

Это время выполнения одного и того же запроса или схожих, но с разными значениями для uid?

Когда тестировал - это рабочий сервер (загруженый) или тестовый?

Такая разницы во времени выполнения постоянно скачет или бОльшее время требуется только при первом обращении к таблице?

во время тестирования нагрузку с машины убирали.

скачет постоянно

 

[flash-vkv]

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

-~{}~ 23.09.06 19:57:

а на другой машине пробовали

 

[chira]

antenne

сколько таких "долгих" запросов на странице, 100-1000, если борьба идёт за милисекунды?
можно услышать объяснение?
всё это похоже на борьбу с ветряными мельницами ...

 

[flash-vkv]

chira странно слышать это от программиста
80мс это не 2мс. Потом чуток там чуток тут и в итоги получаем ошутимый прирост, что иногда бывает ой как необходима

 

[antenne]

chira, борьба с миллисекундами - это борьба за масштабируемость системы.

Если такой запрос на странице будет всего один, то со временем 2мс машина сумеет обработать 500 запросов в секунду, а если он выполняется 80мс - всего 12. Разница очевидна..

На данный момент эксперименты временно приостановлены..

 

[Фанат]

Ох уж мне эти кремлёвские мечтатели...

Если такой запрос на странице будет всего один, то со временем 2мс машина сумеет обработать 500 запросов в секунду, а если он выполняется 80мс - всего 12. Разница очевидна..

Если вдруг придётся выступать на гонках Формулы-1, то жигули там явно не потянут. Разница-то очевидна.

Я полагаю, ты по городу рассекаешь не меньше, чем на болиде?

 

[antenne]

Фанат
дабы не быть голословным, советую вам подписаться на рассылку nginx ( http://sysoev.ru/nginx/ ) и убедиться что веб проекты живущие на нескольких машинах, с предельными нагрузками - это реальность

 

[Фанат]

дада
"Мой брат знает карате, самбо, кунгфу и ещё много других страшных слов!" =)