#std729¶
Общие требования по разработке оптимальных запросов¶
Прежде чем переходить к продвинутым приемам оптимизации, убедитесь, что сам запрос адекватен задаче.
1.1.¶
Минимизируйте объем выборки: выбирайте только данные, необходимые для решения задачи.
Если нужны конкретные поля, не используйте ВЫБРАТЬ *.
Если нужно выполнять свертку, сортировку или вычисления, сначала проверьте, можно ли переложить эти операции на СУБД и сразу получить готовый результат.
1.2.¶
В большинстве случаев следует минимизировать и общее количество запросов к СУБД.
См. также¶
#std436: Многократное выполнение однотипных запросов.
2.¶
Не следует любой ценой переносить выполнение задачи в СУБД: простые запросы СУБД обычно выполняет эффективнее, чем избыточно сложные универсальные.
2.1.¶
Рассматривайте альтернативы:
- подготавливайте несколько более простых запросов под разные предусловия и параметры вместо одного большого универсального запроса;
- выполняйте часть постобработки на сервере 1С:Предприятия средствами встроенного языка.
2.2.¶
Для сложных запросов проверяйте, что СУБД выбирает эффективный план выполнения.
Для DB2, PostgreSQL и Oracle вероятность неудачного плана для сложного запроса выше, поэтому не усложняйте запрос без необходимости.
В первую очередь:
- не добавляйте #std655: вложенные запросы только ради читаемости;
- избегайте сложных условий в
ПОиГДЕ, особенно с #std656: подзапросами в условиях соединения и конструкциейВЫБОР; - используйте минимально необходимое число таблиц в запросе.
Рассматривайте 5–7 таблиц как сигнал возможной чрезмерной сложности, а не как жесткий лимит. В зависимости от структуры таблиц уже при таком количестве время анализа запроса оптимизатором растет нелинейно, и СУБД может выбрать неудачный план выполнения.
План выполнения можно смотреть через консоль запросов, технологический журнал или средства СУБД. Признак проблемного сложного запроса: в плане присутствует timeout warning — оптимизатору не хватило времени выбрать лучший план.
См. также: #std732: Запросы в динамических списках.