Содержание:

1. План выполнения запроса: дорожная карта для СУБД
2. Ключевые операторы и их значение при работе в системе 1С
3. Функционал индексов в 1С

В мире разработки 1С производительность — это поле постоянной битвы. Когда система начинает «тормозить», поверхностные решения, такие как обновление «железа», редко приносят долгосрочный результат. Истинный ключ к скорости лежит в понимании того, что происходит «под капотом» — на уровне взаимодействия платформы 1С с сервером баз данных (СУБД).

Профессиональная оптимизация — это не гадание, а точная наука, основанная на двух китах: анализе планов выполнения запросов и грамотном использовании индексов.

План выполнения запроса: дорожная карта для СУБД

Когда 1С отправляет запрос в MS SQL или PostgreSQL, оптимизатор СУБД немедленно приступает к работе. Его задача — построить наиболее эффективный алгоритм для получения данных. Этот алгоритм и есть план выполнения запроса. Представьте, что это GPS-навигатор: он показывает точный маршрут, по которому сервер пойдет, чтобы найти ваши данные, включая все «пробки» и «объезды».

Чтобы получить этот план, нужно:

1. С помощью Технологического журнала (ТЖ) 1С перехватить «медленный» SQL-запрос, сгенерированный платформой.
2. Вставить этот запрос в среду управления СУБД (например, SQL Server Management Studio — SSMS).
3. Включить опцию «Отображать действительный план выполнения» (Display Actual Execution Plan) и выполнить запрос.

Вы увидите графическую схему, состоящую из операторов. Задача аналитика — «прочитать» эту схему и найти самые дорогие, ресурсоемкие операции.

Ключевые операторы и их значение при работе в системе 1С

1. Scan (Сканирование) vs. Seek (Поиск)
Это самый важный индикатор здоровья вашего запроса.

• Table Scan / Clustered Index Scan: Худший сценарий. СУБД последовательно читает всю таблицу или весь кластерный индекс от начала до конца, чтобы найти нужные строки. Это как искать одного человека в городе, обходя каждый дом. Оператор в плане выглядит как толстая стрелка, а его стоимость (Cost) обычно составляет 90% и более от общей стоимости запроса.
• Index Seek: Идеальный сценарий. СУБД использует существующий некластерный индекс, чтобы мгновенно «прыгнуть» к нужным строкам. Это как найти человека по адресу в записной книжке. Оператор имеет тонкую стрелку и минимальную стоимость.

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

2. Key Lookup (Поиск по ключу)
Это частая и коварная ловушка производительности. Key Lookup возникает, когда СУБД находит нужные данные по некластерному индексу (Index Seek), но в самом запросе требуются поля, которых в этом индексе нет. Тогда серверу приходится совершать дополнительную операцию: для каждой найденной строки обращаться к основной таблице (кластерному индексу), чтобы «добрать» недостающие поля. Это порождает массу точечных чтений и может серьезно замедлить запрос.

3. Sort (Сортировка)
Оператор Sort — один из самых дорогих по потреблению памяти и процессорного времени. Он возникает, когда СУБД нужно отсортировать данные для операций ORDER BY, GROUP BY или для некоторых типов соединений (Merge Join). Частое появление Sort в планах — признак того, что индексы не покрывают потребности запроса в сортировке.

Функционал индексов в 1С

Индекс — это специальная структура данных, которая позволяет СУБД быстро находить строки. Недостаточно просто «накидать» индексов на все поля — это замедлит операции записи. Индексы нужно создавать осознанно.

1. Покрывающий индекс (Covering Index)
Это «святой Грааль» оптимизации. Покрывающий индекс — это некластерный индекс, который содержит все поля, необходимые для выполнения конкретного запроса (из секций SELECT, WHERE и JOIN).

Когда СУБД находит такой индекс, ей вообще не нужно обращаться к основной таблице. Все данные берутся прямо из индекса, что исключает операцию Key Lookup.

• Пример: У вас есть запрос, который выбирает СуммуДокумента и Контрагента из документа РеализацияТоваровУслуг по полю Ответственный.
  • Неоптимальный индекс: Просто по полю Ответственный. План будет содержать Index Seek (поиск по ответственному) + Key Lookup (поиск Суммы и Контрагента в основной таблице).
  • Покрывающий индекс: Индекс по полю Ответственный, который включает в себя (INCLUDE) поля СуммаДокумента и Контрагент. План будет содержать только один быстрый оператор Index Seek.

2. SARGable-запросы: пишем код, понятный для индекса
Даже при наличии идеального индекса, его можно «сломать» неправильно написанным условием. SARGable (Search Argument Able) — это свойство условия, которое позволяет СУБД использовать индекс для поиска.

• Плохо (индекс не используется): ГДЕ ЛЕВ(Номенклатура.Наименование, 4) = “Болт”
  • Причина: СУБД должна применить функцию ЛЕВ() к каждой строке таблицы, прежде чем сравнить результат. Это приводит к Index Scan.
• Хорошо (индекс используется): ГДЕ Номенклатура.Наименование ПОДОБНО “Болт%”
  • Причина: СУБД может напрямую использовать индекс по полю Наименование для поиска всех строк, начинающихся с «Болт».

То же самое касается функций над датами (ГОД(Дата) = 2023 -> Scan) и других преобразований полей в условии WHERE.

Оптимизация производительности в 1С — это итеративный процесс:

1. Найти проблему с помощью замеров производительности и ТЖ.
2. Проанализировать SQL-запрос и его план выполнения.
3. Идентифицировать узкие места (Scan, Key Lookup, Sort).
4. Сформировать решение: создать или изменить индекс (чаще всего, сделать его покрывающим) или переписать запрос в 1С, чтобы он стал SARGable.
5. Проверить результат, убедившись, что план выполнения изменился в лучшую сторону.

Такой глубокий, основанный на данных подход позволяет решать самые сложные проблемы производительности и строить по-настоящему быстрые и масштабируемые системы на платформе «1С:Предприятие».

Специалист компании ООО “Кодерлайн”,

Радченко Степан