БИТРИКС порой использует довольно большие запросы к БД, но суть не в этом, оптимизатор БД порой считает что для выборки по запросу оптимальнее для каких то связей НЕ ИСПОЛЬЗОВАТЬ ИНДЕКСЫ*, хотя те и присутствую.
И хорошо если его выбор в этой политике бы оправдывался, но практика показала, зная что количество записей в БД практически "постоянно", дельта +-10%, то было бы эффективнее использовать всё же ИНДЕКС и тесты показывают время выполнения запроса без индекса в 100 раз медленнее в сравнении с использованием его (в данном случае принудительным).
В битриксе хоть и есть кэш, но для меня это не решение, так как запросы исполняются с условиями фильтрации, кои кешировать мне не хотелось бы, так как последние индивидуальны.
Возник резонный вопрос, как лучше поступить ...
Вижу два варианта развития событий, намеренно исключается вариант использования кэша.
Первый вариант: писать копии компонентов ядра где используется "модифицированные" запросы
Второй вариант: модифицировать их в ядре продукта, но оставлять о них записи в неком файле примечаний проекта
Первый вариант не удобен тем, что при обновлении продукта, терялись перспективы возможного применения каких либо новых плюшек. Так как ваш компонент копия старого... и что бы привести его к виду нового необходимо делать новую копию обновленного компонента и дописывать туда использование индексов.
Второй, по моему мнению все же предпочтительнее, так как хоть при обновлении FORCE INDEX слетает, то имея записи о них, их всегда можно легко восстановить.
хотел бы заметить, что желательно учитывать и тот момент, когда у проекта может сменится разработчик...
спасибо за внимание и ваши дельные советы
---
*Причин такого поведения оптимизатора может быть множество. Если речь конкретно про мой случай, то идет выборка 80% строк таблицы.
И хорошо если его выбор в этой политике бы оправдывался, но практика показала, зная что количество записей в БД практически "постоянно", дельта +-10%, то было бы эффективнее использовать всё же ИНДЕКС и тесты показывают время выполнения запроса без индекса в 100 раз медленнее в сравнении с использованием его (в данном случае принудительным).
В битриксе хоть и есть кэш, но для меня это не решение, так как запросы исполняются с условиями фильтрации, кои кешировать мне не хотелось бы, так как последние индивидуальны.
Возник резонный вопрос, как лучше поступить ...
Вижу два варианта развития событий, намеренно исключается вариант использования кэша.
Первый вариант: писать копии компонентов ядра где используется "модифицированные" запросы
Второй вариант: модифицировать их в ядре продукта, но оставлять о них записи в неком файле примечаний проекта
Первый вариант не удобен тем, что при обновлении продукта, терялись перспективы возможного применения каких либо новых плюшек. Так как ваш компонент копия старого... и что бы привести его к виду нового необходимо делать новую копию обновленного компонента и дописывать туда использование индексов.
Второй, по моему мнению все же предпочтительнее, так как хоть при обновлении FORCE INDEX слетает, то имея записи о них, их всегда можно легко восстановить.
хотел бы заметить, что желательно учитывать и тот момент, когда у проекта может сменится разработчик...
спасибо за внимание и ваши дельные советы
---
*Причин такого поведения оптимизатора может быть множество. Если речь конкретно про мой случай, то идет выборка 80% строк таблицы.