Отбор по субконто ставить на правильный уровень запроса

Правило

В запросах к регистрам с составными измерениями/субконто (контрагент, договор и т.п.) не вешать отбор по субконто на верхнем уровне виртуальной таблицы, если это деградирует план. Тяжёлый отбор выносить на следующий уровень/во вложенный запрос и проверять по плану.

• При жалобе на «иногда долго проводится» — снимать план запроса (PostgreSQL), а не гадать; подозреваемый №1 — отбор по субконто/составному измерению.
• Проверять, что отбор применяется на уровне, где есть индекс и нет полного перебора; при необходимости — вложенный запрос/временная таблица.

Зачем

Виртуальная таблица — это не таблица, а подзапрос с группировкой, который платформа разворачивает на лету. Отбор из её параметров оказывается внутри этого подзапроса, и для субконто/составного измерения (хранится как пара «тип + ссылка», у бухрегистров — в отдельной таблице значений субконто) оптимизатор часто не может использовать индекс — план деградирует до полного перебора всей таблицы регистра. Коварство в том, что деградация выборочная: у одних значений отбора план нормальный, у других — перебор, поэтому «иногда долго проводится» и не воспроизводится на тесте.

Как обнаружить

• Симптом: разброс времени одинаковых операций — сопоставимые документы проводятся за секунды и за минуты.
• Снять план запроса (техножурнал DBPOSTGRS/DBMSSQL или логи СУБД), а не гадать: искать полный перебор (seq scan) большой таблицы регистра.
• Подозреваемый №1 — отбор по субконто/составному измерению в параметрах виртуальной таблицы; подтверждается переносом отбора и повторным замером (см. перф-прогон горячих мест).

Правильно

Правильно

// Сначала сузить выборку по индексируемым измерениям во вложенном запросе,
// тяжёлый отбор по субконто применить к уже суженному набору.
ВЫБРАТЬ Регистратор, Сумма ИЗ (
    ВЫБРАТЬ Регистратор, Контрагент, Сумма
    ИЗ РегистрНакопления.Взаиморасчёты.Остатки
    ГДЕ Организация = &Организация
) КАК Т
ГДЕ Т.Контрагент = &Контрагент

Неправильно

// Тяжёлый отбор по субконто прямо в параметрах виртуальной таблицы —
// план деградирует до полного перебора.
ВЫБРАТЬ Регистратор, Сумма
ИЗ РегистрНакопления.Взаиморасчёты.Остатки(, Контрагент = &Контрагент)

Пример из практики

Перепроведение внутригрупповых поступлений: часть документов перепроводилась 45 секунд против 1–1,5 секунды у сопоставимых, отдельные поступления — по 1,5–3 минуты. Зависание локализовалось в типовом методе УчётВзаиморасчётов.ПолучитьОстаткиАвансов — именно на отборе по субконто контрагента; перенос отбора «на следующий уровень» вернул нормальное время. Та же первопричина потянула за собой соседние инциденты — многочасовое групповое перепроведение и непроходящее ТиИ: один неудачный уровень отбора в часто вызываемом методе оплачивается везде, где этот метод дергается.

Когда не применять

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

См. также

• Автозаполнение реквизитов документов — предсказуемо и в нужный момент
• Долгие и большие операции интеграций — асинхронно
• Закрытый период и дата запрета редактирования
• Изменения в горячих местах сопровождать перф-прогоном
• Измеренный RTO, регулярный тестовый restore и проходящий ТиИ
• Короткие транзакции и каноничный шаблон
• Не выполнять однотипные запросы в цикле
• Проверка ОбменДанными.Загрузка в обработчиках событий
• Проверять пустой результат запроса методом Пустой()
• Соединения в запросах — без подзапросов и виртуальных таблиц

• Изменения в горячих местах — с перф-прогоном