Как ускорить запросы в 1С: оптимизация запросов для повышения производительности

«1С тормозит» почти никогда не означает, что всё сломалось. Чаще это история про несколько запросов, которые либо выполняются слишком долго, либо запускаются так часто, что “съедают” ресурсы базы и кластера. При этом сам механизм запросов в 1С изначально сделан для быстрого получения выборок из больших массивов данных — просто в реальной жизни ему мешают объёмы, неверная логика отбора, сортировки, JOIN’ы, планы выполнения и блокировки.

Ниже — логика, по которой действительно удобно ускорять запросы: сначала находим виновников по фактам, затем быстро нивелируем самые “жирные” запросы, потом уже лезем в планы/индексы/блокировки и закрепляем результат мониторингом.

1) Шаг “0”: сначала найдите какие запросы тормозят (а не “улучшайте всё подряд”)

Главная ошибка в оптимизации — переписывать запросы наугад. В продакшне важны две категории:

• самые длительные запросы (бьют по отклику и “держат” транзакции),

• самые частые (каждый по 50–200 мс, но суммарно дают нагрузку и очереди).

И вот здесь обычно начинается боль: “а где взять статистику?” — техжурнал, выгрузки, Excel, ручной разбор, попытки поймать пик.

Как это делает Metrika42

Metrika42 как раз закрывает “нулевой шаг”: она непрерывно (24/7) собирает метрики по запросам к базе, времени операций, блокировкам и состоянию серверов/СУБД.
Дальше — показывает это в понятных экранах “топ частых вызовов / топ длительных запросов / запросы по пользователям + разрез по процессам кластера”.
А если нужно быстро сузить расследование, новые дашборды позволяют фильтровать и сортировать метрики по времени, пользователю, базе данных и др. критериям — чтобы не копать “вслепую”.

Иными словами: вместо “кажется, отчёт медленный” вы получаете список конкретных запросов и сценариев, которые реально формируют нагрузку.

2) Быстрые приёмы оптимизации запроса в 1С, которые чаще всего дают эффект

Когда “виновник” найден, дальше обычно работает простой принцип: уменьшить объём данных и сложность работы СУБД.

Сузьте выборку как можно раньше

• ограничьте период (если период “вся история” — почти всегда это и есть причина),

• добавьте отборы по организации/складу/статусу/типу операции,

• если нужны только итоги — не тяните детализацию “на всякий случай”.

Не выбирайте лишние поля

Каждое дополнительное поле — это лишнее чтение/соединение/передача. Особенно тяжело, когда вы подтягиваете реквизиты через связи, которые пользователю в итоге “не пригодились”.

Осторожнее с сортировками и группировками

УПОРЯДОЧИТЬ ПО и сложная агрегация — частые “усилители боли” на больших объёмах. Если сортировка нужна только для удобства на форме, иногда выгоднее:

• сначала отфильтровать/агрегировать минимум,

• затем сортировать уже маленький набор.

Проверьте соединения (JOIN)

Два типовых “убийцы”:

• соединения, которые раздувают результат (неожиданная многократность),

• соединения по полям, под которые в базе нет хорошей поддержки (план уходит в сканирование больших объёмов).

3) Воспроизведите проблему в контролируемых условиях и посмотрите план

После быстрой “диеты” важно убедиться, что запрос стал легче не только “логически”, но и по факту выполнения.

Консоль запросов (как быстрый стенд для экспериментов)

Официальная Консоль запросов в 1С — это внешняя обработка, которую можно запустить в любом прикладном решении: вы составляете текст запроса, запускаете его, задаёте параметры и анализируете результат.
Полезный бонус: консоль может записать план выполнения запроса, а изучение плана часто помогает найти, где именно теряется время.

Идеальный подход: сделать 2–3 версии запроса и сравнить:

• время выполнения,

• число строк в промежуточных наборах,

• влияние сортировки/агрегации/соединений.

4) СУБД-уровень: когда без статистики и индексов запрос “не взлетит”

Даже “красивый” запрос может быть медленным, если СУБД выбирает неудачный план. Здесь две ключевые темы: планы выполнения и статистика/индексы.

PostgreSQL: EXPLAIN ANALYZE и актуальная статистика

• EXPLAIN (ANALYZE …) выполняет запрос и показывает фактические времена и статистику исполнения — это база для понимания, где именно дорого.

• Команда ANALYZE собирает статистику по данным таблиц, и планировщик использует её, чтобы выбирать более эффективные планы.

SQL Server: обслуживание индексов тоже влияет на скорость

Со временем операции вставки/обновления/удаления могут приводить к “рассыпанию” страниц индекса (фрагментации), из-за чего запросам нужно больше I/O. В документации Microsoft прямо описано, что фрагментация и плотность страниц влияют на производительность и что для обслуживания используют reorganize/rebuild в зависимости от ситуации.

5) Не забывайте про блокировки: иногда запрос “медленный”, потому что он ждёт

Бывают ситуации, когда запрос сам по себе нормальный, но:

• попадает в очередь,

• ждёт освобождения ресурса,

• “цепляет” долгую транзакцию другого процесса.

В таких кейсах ускорение достигается не переписыванием SELECT, а уменьшением времени транзакций, корректировкой последовательности действий, разнесением регламентных операций и т. п.

В Metrika42 блокировки — это отдельная зона диагностики: сервис показывает события и контекст (в т.ч. по техжурналу), а также помогает быстрее разобраться “кто и кого держит”.

6) Как сделать ускорение устойчивым: мониторинг и предупреждения вместо “жалоб пользователей”

Даже если вы ускорили самые больные запросы, через месяц ситуация может вернуться из-за роста базы, релизов, новых отчётов и изменения нагрузки. Поэтому нужен контроль, который:

1. показывает деградации,

2. сигнализирует заранее,

3. помогает быстро локализовать причину.

Что даёт Metrika42 для этого “контура контроля”

• Оповещения до жалоб пользователей: система уведомлений предупреждает о просадке APDEX, медленных запросах и перегрузке серверов, в том числе через Telegram-бота.

• Понятные дашборды по запросам: топ длительных/частых, разрез по пользователям и процессам кластера — чтобы каждый инцидент начинался не с догадок, а с фактов.

• Ежемесячный экспресс-аудит (если нужна “рука эксперта”): формирование списка проблем в 1С и СУБД, объяснение причин, рекомендации и приоритизация, плюс настройка порогов и логики уведомлений (в т.ч. по медленным запросам).