1С:Предприятие 8.2 /
Разработчикам /
Реализация обработки данных

Оглавление

Общие требования по разработке оптимальных запросов

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

Методическая рекомендация (полезный совет)

Прежде чем перейти к более продвинутым методам оптимизации запросов, необходимо убедиться, что сам запрос – адекватен решаемой задаче.

1.1. Следует минимизировать объем выборки таким образом, чтобы выбирать ровно те данные, которые требуются для решения задачи.
Например, если нужно получить значения конкретных полей, не следует выбирать все поля «на всякий случай» с помощью конструкции ВЫБРАТЬ * ИЗ …
Вместо выборки большого объема данных для их последующей обработки (свертка, сортировка, проведение вычислений и пр.) на сервере 1С:Предприятие , следует, в первую очередь, ответить на вопрос: «А есть ли возможность переложить эту работу на базу данных, чтобы получить уже готовый результат?»

1.2. Также в большинстве случаев, следует минимизировать и общее количество запросов к СУБД.

См. также: Многократное выполнение однотипных запросов.

2. С другой стороны, не следует пытаться любой ценой перенести выполнение задачи в СУБД. СУБД обычно оптимизирует и выполняет простые запросы более эффективно, чем сложные.

2.1. Следует рассмотреть альтернативные меры:

• по подготовке различных (более простых, частных) текстов запроса в зависимости от предусловий и значений параметров запроса – вместо отправки в СУБД одного большого универсального запроса;
• по более эффективной постобработке данных, выбранных запросом из СУБД, на стороне сервера 1С:Предприятия средствами встроенного языка.

2.2. При разработке запросов нужно быть уверенным, что они использует эффективные планы выполнения запросов. Для сложных запросов СУБД с высокой вероятностью выберет неправильный план выполнения запроса, что особенно актуально для СУБД DB2, PostgreSQL и Oracle.
Поэтому не следует неоправданно усложнять запрос, в первую очередь:

• Не следует добавлять вложенные запросы только для повышения читаемости.
• Избегать сложных условий соединения и в предложении ГДЕ, в особенности содержащие подзапросы и конструкции ВЫБОР.
• Использовать в запросе минимально необходимое число таблиц. В зависимости от структуры таблиц, много может быть уже и 5-7 таблиц в одном запросе (время, затрачиваемое оптимизатором СУБД на анализ запроса, растет нелинейно, в итоге получается плохой план выполнения).

Для того чтобы узнать, какой план выполнения запроса выбран оптимизатором СУБД, можно воспользоваться консолью запросов, технологическим журналом или средствами СУБД. Как правило, запрос – сложный и будет плохо выполняться, если в скомпилированном плане выполнения запроса есть timeout warning, который означает, что оптимизатору СУБД не хватило времени на поиск наилучшего плана запроса.

См. также:Запросы в динамических списках

Нас находят: многократное выполнение однотипных запросов