Загальні вимоги щодо розробки оптимальних запитів

Область застосування: керований застосунок, мобільний застосунок, звичайний застосунок.

Методична рекомендація (корисна порада)

Перш ніж перейти до більш просунутих методів оптимізації запитів, необхідно переконатися, що сам запит – адекватний завданню, яке розв’язується.

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

1.2. Також у більшості випадків слід мінімізувати й загальну кількість запитів до СУБД.

Див. також: Багаторазове виконання однотипних запитів.

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

2.1. Слід розглянути альтернативні заходи:

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

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

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

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

Див. також: Запити в динамічних списках