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

Так я и говорю: зачем делать эти запросы?

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

В итоге у тебя вместо 100к запросов будет 1 на выборку и штук 10 батчей на запись.

Почему не одним скриптом/запросом ? (всё выбрали, все скомпоновали, всё записали)

Или речь о том, что у вас долго отрабатываются 100.000 инсертов ?

Если так - гуглите в сторону отключения на это время индексов, оборачивание в транзакции итп,

но у меня и миллионы без проблем импортируются, и довольно быстро.

Но в целом... "какая-то дичь".

Если хотите это место "кардинально разгрузить", то решением был бы некий демон к nginx-у...

Но, скорее всего, вам это всё не надо вовсе, я как-то сомневаюсь, что у вас сотни тысяч хитов в час...

Я видимо чего то не знаю.

Вернее, я понимаю, что можно взять все товары из бд, закинуть данные по массивам....

$massid[] = айди

$masszvet[] = цвет

$massrazmer[] = размер

$masstype[] = типа

ну либо через многомерный массив

$mass[] = array("id"==>"айди", "zvet"==>"цвет", "razmer"==>"размер" );

далее есть список вариантов запросов, в массиве $massvariantov

foreach ($massvariantov as $value) {

Но я не придумал, как из массивов делать выборку аналогично запросу к базе - where соблюдены_условия_такие_то

}

Мощно... т.е. вы не можете найти элемент в массиве, и для этого 100.000 раз гоняете запросы к БД :) ?

Гуглите "поиск элемента в массиве "язык"".

Если речь о массиве из 2000 элементов, то можно попробовать и перебором, всё равно должно быть быстрее чем с БД.

Если массив большой, то придется использовать нормальный поиск (сортировать к примеру, а далее делением пополам)

Если массив огромный, в сотни тысяч-миллионы записей, то тут да - придется использовать БД.

Вы изначально какую-то "муть" делаете... что-то у вас изначально в идее порочное.

Даже если это "заранее прогретый кеш", то непонятно всё-равно зачем к БД с 2000 строк делать 100.000 запросов.

Это не может быть нормальным её использованием.

Если у вас 100.000 инсертов, то яб подумал о том, чтобы генерить скрипт с ними, а затем его исполнять "в одну транзакцию".

(ну или порезать кусками по 10к, смотря как быстрее будет получаться)

Любитель. Этим занимаюсь не профессионально. У меня другая работа. Ну, это так, к слову))

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

Про "порочное" со 100тыс запросов -согласен. Я же понимаю ,что 100тыс запросов (в фильтрах) даже юзеры на сайте не сделают за 2 месяца.

Логика работы должна быть следующая.

1. Одним запросом загружаете всё из базы

2. Далее в памяти всё так как надо комбинируете

3. Результат либо загружаете в базу сразу, либо если много генерируете скрипт для загрузки и потом его исполняете (можно кусками).

Я не очень по вашему описанию вообще понимаю что вы там и зачем делаете, понимаю только, что путь явно порочный, но скорее всего ничего этого делать не надо вовсе, а надо как-то скрипт так доработать, чтобы при запросе пользователей он и запускался... вызывает большое сомнение, что у вас такой поток пользователей, что эта часть требует серьезной оптимизации.

Обычно, для многих языков есть готовые find/search, которые позволяют находить значения не перебором, в этом направлении следуюет документацию изучить. Но после того, как станет ясно, что "с перебором тормозит". Потому, что может оказаться, что и перебором будет всё работать с достаточной скоростью.

Я признаться вообще не понимаю зачем вам там поиск. Если вы для каждого варианта что-то генерите, генерите последовательно... и всё.

Он так сейчас для пользователей и работает...

Спасибо.

тему можно закрыть.

Так и не трогайте базу, зачем вы какие-то 100.000 запросов делаете ?

............

пока могу сказать только - надо. тестирую новый вариант.

их увеличится вдвое, т.к. добавится ещё пара характеристик фильтрации. Попробую сделать через массивы.

Вам нужно пересмотреть дизайн базы: на 2к товарах выборки должны быть очень быстрые, если дизайн правильный составить. У меня на 3 млн. товаров фильтры до 40 мс. занимают.