Надо сделать 103тыс запросов к базе

Можно на порции разбивать запросы

Запускайте ночью по крону.

Нужно посмотреть на сколько сам по себе сложный запрос, и возможно упростить его до нескольких очередных запросов. Сделать explain.

Если надо регулярно делать сотню тысяч запросов к базе, то в консерватории что-то "КРУПНО НЕТАК"

Переписать так, чтобы запросов к базе надо было сделать три-пять... она (база) в общем-то только для этого и нужна...

Либо делить на части и запускать частями.

То, что при увеличении числа запросов становится "еще медленнее" как-бы намекает на то, что где-то что-то сделано ОЧЕНЬ ПЛОХО. (память там не освобождается, или еще какие ресурсы).

Psionik, _SP_

У нас 2000 товаров. У каждого 6 характеристик - цвет, размер, тип и т.д.

Брали все характеристики, уникализировали, перемешивали (составляя все возможные комбинации) и делали запросы к БД (в итоге их получалось 100тыс), чтобы сохранить id товаров соответствующие каждому запросу.

Минимизировали кол-во запросов до 8тыс. Перемешивали характеристики не всех товаров, а каждого (из 2000 поочереди). Потому что там где получалось 100тыс - в итоге по 92тыс не было ни одного товара подходящего под условия.

А теперь для каждого товара перемешали варианты запросов по характеристикам и получили составили запросы типа

where zvet='blu'

where zvet='blu' AND razmer='15*15'

where zvet='blu' AND strana='Италия'

и т.д.

где 100% есть хоть один товар отвечающий запросу. Где то само собой больше, при частичном совпадении характеристик у других товаров.

Как то так, вообщем. Условно составили ответы для запроса в фильтре заранее, записав их в бд.

Что-то очень и очень странное. Зачем кешировать запросы фильтра?

На 2к записей выборка должна быть чуть быстрее чем скорость света.

Ок, хотим кешировать фильтры, так давайте кешировать популярные (по мере их поступления), зачем кешировать все подряд?

NothingMatters, не кешировать. Записываем в бд id товаров соответствующих тому или иному варианту фильтрации товара.

Когда юзер фильтранул, просто берем список id из БД соответствующих его запросу.

Есть основания так сделать заранее (запись в бд). Пока что не хотел бы их (основания) разглашать. В тестировании.

Понимаю, что "на лету" это все просто формируется...

Ну это кеширование ответа.

Можно тупо сделать выборку всех товаров, фильтрануть их на стороне скрипта, и в БД уже записать результат батчем.

Не вижу смысла делать сотни тысяч запросов тут.

Вариантов, как обычно, есть несколько и их можно сочетать.

1. Оптимизация запросов.

В консоли mysql напишите:

set profiling=1;

select .... <сам запрос>

show profile;

Так сможете посмотреть, какие этапы запроса отрабатывают медленно и их оптимизировать.

2. Разбиение запросов на порции.

Если небольшие блоки запросов выполняются быстро - разделить 100к запросов на блоки по несколько тысяч и выполнять их по очереди.

3. Масштабирование БД

Добавить 1 или несколько slave-серверов и распределить запросы между ними, при необходимости - через балансировщик вроде haproxy.

100тыс запросов, это вообще все возможные комбинации фильтра.

Понимаете от куда такое число?