В практике разработчика 1С нередко встречается парадоксальная ситуация: простой запрос к одной таблице с элементарным фильтром по дате в консоли запросов выполняется мучительно долго (иногда часами), хотя в коде приложения или при помещении во временную таблицу тот же самый код отрабатывает за секунды. Мы часто виним в этом индексы, нагрузку на сервер или блокировки, но истинная причина может скрываться в механизмах самой платформы и особенностях визуализации данных.
В данной статье мы подробно проанализируем ситуацию на примере реального кейса, когда запрос к документам ЧекККМ возвращал 407 000 строк и вешал систему. Разберем по шагам, почему это происходит и как правильно работать с большими выборками данных.
Рассмотрим типичный запрос, который на первый взгляд не должен вызывать проблем:
ВЫБРАТЬ
ЧекККМ.Ссылка КАК Ссылка,
ЧекККМ.Номер КАК Номер,
ЧекККМ.Дата КАК Дата
ИЗ
Документ.ЧекККМ КАК ЧекККМ
ГДЕ
ЧекККМ.Дата МЕЖДУ &НачалоПериода И &КонецПериода
Автор проблемы столкнулся с тем, что этот текст в консоли запросов выполнялся 2 часа. Однако, стоило лишь изменить запрос, добавив помещение во временную таблицу, как время выполнения сокращалось до 1.5 секунд:
ВЫБРАТЬ
ЧекККМ.Ссылка,
ЧекККМ.Номер,
ЧекККМ.Дата
ПОМЕСТИТЬ ВТ_Чеки
ИЗ
Документ.ЧекККМ КАК ЧекККМ
ГДЕ
ЧекККМ.Дата МЕЖДУ &НачалоПериода И &КонецПериода
Выясним причину такого колоссального разрыва в производительности.
Самая главная проблема при работе с большими объемами данных в консоли — это вывод результата в табличный документ. Когда мы выполняем запрос в интерактивной консоли, платформа должна не просто получить данные из SQL, но и отрисовать их в ячейках формы.
Проанализируем, что происходит при получении 407 000 строк:
ТабличныйДокумент. Это требует огромного объема оперативной памяти.Именно поэтому вариант с ПОМЕСТИТЬ работает быстро — в этом случае данные остаются внутри СУБД (в TempDB) и не передаются «наружу» для отрисовки. Время 1.5 секунды — это чистое время работы SQL-сервера по выборке данных.
Когда в поле выборки присутствует Ссылка, консоль запросов при выводе пытается показать пользователю понятное строковое представление документа (например, «Чек ККМ №001 от 01.01.2023»).
Если механизм получения представлений в конкретной консоли не оптимизирован, может возникнуть проблема N+1 запроса. Платформа для каждой из 400 тысяч строк может делать отдельный микро-запрос к базе данных, чтобы сформировать строку представления. Даже если это происходит пачками, нагрузка на систему возрастает экспоненциально.
Рекомендация: Чтобы ускорить получение данных, если вам нужно только представление, используйте функцию ПРЕДСТАВЛЕНИЕ(Ссылка) или ПРЕДСТАВЛЕНИЕССЫЛКИ(Ссылка) прямо в тексте запроса. В этом случае сервер 1С сформирует строковое описание объекта на своей стороне и передаст клиенту уже готовую строку, а не тяжелую ссылку.
Если в базе настроены права доступа на уровне записей (RLS), любой запрос к документам автоматически модифицируется платформой. Рассмотрим подробнее: простой ВЫБРАТЬ... ИЗ Документ.ЧекККМ превращается в сложную конструкцию с несколькими JOIN к таблицам прав доступа.
При использовании RLS даже помещение во временную таблицу может замедлиться, так как системе нужно проверить право на чтение каждой из 400 тысяч записей. Проанализируем ситуацию: если запрос под полными правами работает быстро, а под ограниченными — медленно, значит, проблема именно в правилах RLS.
Рассмотрим по шагам, как правильно работать с такими объемами данных, чтобы не блокировать работу системы и не ждать часами результата.
1. Использование СКД (Система компоновки данных)
Если вам действительно нужно увидеть или проанализировать 400 000 строк, вместо консоли запросов лучше использовать отчет на базе СКД. Механизмы вывода в СКД гораздо лучше оптимизированы для работы с большими коллекциями данных. СКД умеет выводить данные порциями и более эффективно работает с оперативной памятью.
2. Выгрузка в таблицу значений в коде
Если запрос выполняется внутри алгоритма (в модуле), используйте метод Выгрузить(). Это создаст таблицу значений в памяти сервера, что происходит в десятки раз быстрее, чем вывод в интерфейс:
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ ЧекККМ.Ссылка, ЧекККМ.Номер ИЗ Документ.ЧекККМ КАК ЧекККМ";
РезультатЗапроса = Запрос.Выполнить();
// Это отработает быстро:
ТаблицаРезультата = РезультатЗапроса.Выгрузить();
3. Отказ от выбора ссылок без необходимости
Если вам нужно просто посчитать количество или получить номера документов, не выбирайте поле Ссылка. Выбирайте только примитивные типы (числа, строки, даты). Обработка примитивных типов данных платформой 1С происходит значительно быстрее.
4. Пакетная обработка данных
Для обработки 400 000 документов правильнее использовать порционное чтение. Разберем пример реализации через ограничение количества строк:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ ПЕРВЫЕ 1000
| ЧекККМ.Ссылка
|ИЗ
| Документ.ЧекККМ КАК ЧекККМ
|ГДЕ
| ЧекККМ.Дата МЕЖДУ &Начало И &Конец
| И ЧекККМ.Ссылка > &ПоследняяСсылка
|УПОРЯДОЧИТЬ ПО
| Ссылка";
// Далее в цикле меняем параметр &ПоследняяСсылка
Выясним краткие выводы из нашего исследования:
ПОМЕСТИТЬ работает быстро, значит индексы в порядке и СУБД справляется.ПРЕДСТАВЛЕНИЕ() помогает избежать лишних обращений к базе при отрисовке ссылок.Помните, что 1С:Предприятие — это в первую очередь система бизнес-автоматизации, и ее интерфейсные механизмы не предназначены для прямого отображения «сырых» данных объемом в полмиллиона записей в одной экранной форме.