Из недавней практики оптимизации работы запроса в 1С.
Ниже приведен запрос, который выполнялся около 10 минут.
Внешне запрос выглядит более чем обычно – выбор данных всего из одного регистра по нескольким условиям. Пытаясь понять причину столь медленной работы запроса, я начал поэтапно исключать все условия, пока полностью не упростил запрос:
Результата это не дало – запрос продолжал работать 8-10 минут, чтобы получить просто 100 сгруппированных записей. Запустил MS Profiler, чтобы посмотреть, как данный запрос выглядит на SQL Server. Результат поверг в легкое недоуменение – MS Profiler намертво зависал при попытке отобразить текст данного запроса. Сохранив трассу MS Profiler в файл и открыв его в текстовом редакторе, я увидел запрос на несколько тысяч строк, который использовал таблицы документов. Ответ нашелся в конфигураторе и оказался очень простым:
Так как может выбираться любой документ, то 1С для данной выборки объединяет ВСЕ существующие в 1С документы в один запрос. Естественно системе становится плохо даже при мысли о выполнении такого гигантского объединения таблиц )))
Исправить ситуацию можно приведенным ниже способом. Простым запросом получить все типы документов, которые используются в данном регистре:
Поставить галочки только для них. Выполнить обновление базы и запрос начинает работать за несколько секунд. На понимание – я выполнил ускорение работы запроса с 10 минут до 2-3 секунд. Масштаб снижения нагрузки на сервер базы данных и жесткие диски колоссальный. Особенно для приведенного случая – это интерфейс, который стартует каждые 15 минут – то есть работает ПОСТОЯННО.
Ниже приведен анализ работы запросов на новой структуре на основании данных SQL Server (Duration – время в миллисекундах):
- Первые три строчки – показывают работы простейшего запроса TOP 100 (вторая и третья быстрее – так как запрос закешировался)
- Четвертая строчка – это запрос на поиск уникальных типов документов
- Пятая строчка – это оригинальный запрос, который работает в рабочей базе для определения данных на выгрузку в другую систему (его текст приведен в самом начале поста).
Вывод: архитектурное решение, когда разработчику проще поставить одну галочку не включая мозг, крайне не рекомендуется к использованию, так как требует очень аккуратного написания запросов, что для работы большой команды почти невыполнимая задача.