[B][SIZE=14pt]Вот что Битрикс ответил после недельной переписки:
[/SIZE][/B][B][SIZE=14pt] - проблема не распространенная и вообще не типовой случай...[/SIZE][/B]
"Обычно такая задача решается разделением на инфоблоки (по разделам или по типам).
Каких-то штатных средств нет для ускорения продукта при таком количестве свойств."
"Прочитайте статью наших специалистов по производительности:
[URL=https://www.itsumma.ru/blog/problemy-proizvoditelnosti-saytov-na-1c-bitrix]https://www.itsumma.ru/blog/problemy-proizvoditelnosti-saytov-na-1c-bitrix[/URL]
Особенное внимание уделите пункту "Неправильная структурная организация инфоблоков".
Я думаю, что часть вопросов пропадёт.
Если у вас есть предложения по развитию продукта, пишите на наш сайт идей: [URL=http://idea.1c-bitrix.ru/]http://idea.1c-bitrix.ru/[/URL]
Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию."
В самой статье ничего нового, а по этой теме привожу отрывок -
"[B]Неправильная структурная организация инфоблоков[/B]
Пожалуй, это наиболее распространенная проблема — [B]встречается в 90% проектах [COLOR=#ff0000](а Битрикс сказал, что не типичная проблема)[/COLOR][/B]. Когда все товары «складывают» в один инфоблок. У такого инфоблока накапливается большое количество свойств всех товаров, это чревато большими выборками и медленным импортом. Рассмотрим на примере абстрактного спортивного магазина, у которого в ассортименте одежда, лыжи, велосипеды (и у каждого вида товаров свои свойства). Свойства товаров попадают в один инфоблок, велосипеды получают свойства лыж и одежды (и, соответственно, наоборот — данные виды товаров получают свойства велосипедов). Представьте, сколько «избыточных» свойств накапливается, если категорий товаров у магазина много.
При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё."