Часто в процессе разработки конфигураций на платформе 1С возникает задача найти все документы, подчиненные определенному объекту (например, заказу покупателя). Стандартным механизмом для таких целей являются КритерииОтбора. Однако, как показывает практика, на больших объемах данных этот инструмент может работать крайне медленно. Давайте разберем, почему это происходит и как оптимизировать поиск, чтобы система работала быстро и предсказуемо.
Когда вы выполняете запрос к КритериюОтбора, платформа фактически совершает «объединение» (UNION ALL) всех таблиц, которые включены в состав этого критерия. Система вынуждена сканировать индексы или даже целые таблицы всех типов документов, указанных в составе, чтобы найти подходящие записи. Даже если вам нужен только один конкретный вид документа, СУБД тратит ресурсы на проверку всей цепочки связанных объектов. В итоге, чем больше типов документов в составе критерия, тем медленнее выполняется запрос.
Самый эффективный и быстрый способ поиска — это обращение напрямую к таблице данных, где хранится связь. Если мы точно знаем, что ищем подчиненные документы (например, ПлатежныеПорученияВходящие), и знаем, в каком поле лежит ссылка на родительский документ (например, реквизит Сделка), нет смысла использовать критерий отбора.
Рассмотрим, как написать такой запрос правильно:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ППВ.Ссылка КАК Ссылка
|ИЗ
| Документ.ПлатежноеПоручениеВходящее.РасшифровкаПлатежа КАК ППВ
|ГДЕ
| ППВ.Сделка = &Заказ";
Запрос.УстановитьПараметр("Заказ", СсылкаНаЗаказ);
Результат = Запрос.Выполнить();
Важные рекомендации по этому методу:
Сделка), имеет свойство Индексировать установленным в значение Индексировать или Индексировать с доп. упорядочиванием. Без индекса запрос будет выполнять полное сканирование таблицы, что на больших объемах приведет к резкому падению производительности.ОБЪЕДИНИТЬ ВСЕ. Это даст СУБД четкий план выполнения, который будет работать на порядки быстрее любого универсального механизма платформы.Если задача поиска связанных документов возникает постоянно, а структура связей сложная (например, документ может быть основанием для десятков разных видов объектов, расположенных в разных частях конфигурации), лучшим решением будет использование РегистраСведений.
Алгоритм внедрения:
РегистрСведений.ДокументОснование (тип - любая ссылка на документ) и измерение СвязанныйДокумент (тип - любая ссылка на документ).Этот метод считается «золотым стандартом» в промышленной разработке 1С. Вы один раз тратите ресурсы при записи документа, чтобы потом мгновенно получать результат при чтении. Это классический пример обмена «места на диске» на «скорость выполнения».
В ходе анализа проблемы были выявлены распространенные ошибки, которые могут привести к непредсказуемым результатам:
Использование ПолучитьСписокДокументовПоКритериюОтбора(): Как было отмечено в обсуждении, этот метод часто возвращает дублирующие записи (например, последний результат повторяется несколько раз). Это происходит из-за особенностей логики платформы при сопоставлении данных из различных таблиц состава критерия. Использование прямых запросов полностью исключает такие ошибки.
Излишняя универсальность: Не пытайтесь оптимизировать критерии отбора, удаляя из них часть аналитики. Если вы заранее знаете структуру данных, лучше отказаться от универсальных механизмов в пользу явных запросов. Помните: лучше дописать пару строк кода для прямого запроса, чем загружать базу «тяжелыми» универсальными конструкциями, которые нагружают сервер СУБД.
Подводя итог, можно сказать: если вы стремитесь к высокой производительности, всегда отдавайте предпочтение прямому обращению к таблицам базы данных или используйте специализированные регистры сведений. Это обеспечит стабильную работу системы даже при существенном росте объема данных.