← На главную

Переход от написания прикладных запросов 1С к пониманию низкоуровневой работы СУБД — закономерный этап профессионального роста каждого разработчика платформы. Зачастую специалист сталкивается с дилеммой: с чего начать изучение, если нет системного опыта администрирования, а абстрактные учебники по реляционным базам данных дают мало пользы в контексте специфики платформы 1С:Предприятие. Разберем по шагам, как выстроить практический путь освоения СУБД (будь то Microsoft SQL Server или PostgreSQL), какие механизмы платформы влияют на физическую базу данных и что действительно нужно знать для решения реальных задач оптимизации.

Шаг 1. Начинаем с измерений: локализация узких мест в коде

Главная ошибка при знакомстве с СУБД — начинать с абстрактного чтения толстых справочников или настройки планов обслуживания без понимания того, как система генерирует нагрузку. Проанализируем правильный подход: любое изучение работы базы данных должно начинаться с конкретной проблемы в рабочей базе (медленный отчет, тяжелое проведение документа или зависающий обмен).

1. Замер производительности в конфигураторе: Запустим замер и оценим вклад кода 1С в общее время выполнения операции. Очень часто проблемы, списываемые на неоптимальный SQL, вызваны циклами, чтением объектов в цикле или чрезмерным обращением к серверу.
2. Перенос логики в параметры запроса: Разберем типичный случай, когда неоптимальная фильтрация данных выполняется на стороне платформы или в соединении уже после выборки. Наложение отборов непосредственно внутри параметров виртуальных таблиц (например, срезов последних или оборотов регистров) позволяет СУБД с самого начала отсечь ненужные строки и ускорить запрос в сотни раз.

Шаг 2. Анализ планов выполнения запросов

Когда мы убедились, что задержка возникает именно на стороне СУБД, перейдем к анализу плана выполнения (Execution Plan). Это фундаментальный навык разработчика, вокруг которого строится вся дальнейшая оптимизация.

Рассмотрим, на какие элементы плана необходимо обращать внимание в первую очередь:

1. Способ чтения таблиц: Выясним, как СУБД читает данные — через сканирование всей таблицы (Index Scan, Table Scan / Seq Scan) или через точечный поиск по индексу (Index Seek). Отсутствие подходящего индекса превращает выборку в чтение миллионов страниц с диска.
2. Физические операторы соединений: Обратим внимание, как объединяются наборы данных. Легкие соединения типа Nested Loops эффективны на малых выборках, но при миллионах строк приводят к катастрофическому падению скорости. Соединения Hash Match или Merge Join требуют адекватной оценки объемов строк оптимизатором.
3. Расхождения расчетных и фактических строк: Сравним ожидаемое оптимизатором количество строк (Estimated Rows) с фактическим (Actual Rows). Если оптимизатор ожидает 1 строку, а получает 500 000, он выберет неверный алгоритм соединения.

Шаг 3. Внутренняя механика трансляции 1С в SQL

Платформа 1С:Предприятие экранирует разработчика от чистого SQL, однако при выполнении запроса происходит строгая трансляция конструкций платформы в команды реляционной СУБД. Посмотрим, как прикладной код отражается на физическом уровне:

1. Разыменование ссылочных полей через точку: Каждое обращение вида Документ.Контрагент.Город транслируется движком платформы в физический LEFT JOIN к соответствующим таблицам. Цепочки из нескольких точек в тексте запроса генерируют громоздкие деревья соединений, перегружающие оптимизатор.
2. Временные таблицы и база tempdb: Использование конструкции ПОМЕСТИТЬ создает реальную физическую таблицу во временной базе СУБД (tempdb в MS SQL или схеме pg_temp в PostgreSQL). Если во временную таблицу помещается большой массив данных, необходимо явно создавать индексы по полям, которые в дальнейшем участвуют в соединениях или фильтрах, чтобы исключить сканирование промежуточных таблиц.
3. Формат данных: Таблицы и поля 1С получают системные имена с внутренними идентификаторами, а ссылочные типы хранятся как 16-байтные бинарные значения (UUID). Прямое чтение или сопоставление этих полей требует понимания структуры хранения метаданных.

Шаг 4. Управление транзакциями, блокировки и конкурентность

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

1. Управляемые блокировки и версионность: В современных конфигурациях используется режим управляемых блокировок. На уровне СУБД чтение не должно блокировать запись. Для MS SQL Server обязательным требованием является включение режима READ_COMMITTED_SNAPSHOT (RCSI). В PostgreSQL версионность (MVCC) работает из коробки.
2. Эскалация блокировок: В Microsoft SQL Server при изменении более 5000 строк в одной транзакции СУБД автоматически блокирует всю таблицу целиком, парализуя параллельные процессы. Чтобы избежать этого, разбиваем массивные операции на порции или отключаем эскалацию для конкретных высоконагруженных таблиц.
3. Взаимоблокировки (Deadlocks): Разберем природу дедлоков: они происходят, когда две транзакции захватывают одни и те же ресурсы в разном порядке. Исключаем подобные коллизии путем единого порядка обновления регистров и документов, а также сокращением времени нахождения внутри транзакции.

Шаг 5. Статистика, ожидания и регламентное обслуживание

Нередко возникает ситуация: код не менялся, объем данных вырос незначительно, но система резко замедлилась. Выясним причину такого поведения:

1. Актуальность статистики: Оптимизатор строит план запроса на основе распределения значений в столбцах. Если статистика устарела, план запроса деградирует, а промежуточные данные могут вытесняться на диск (Spill to tempdb / Workfile). Регулярное обновление статистики — ключевая регламентная процедура.
2. Обслуживание индексов: При интенсивной записи, вставке и удалении данных индексы фрагментируются. Настроим периодическую реорганизацию и перестроение (реиндексацию) таблиц в периоды наименьшей активности пользователей.
3. Резервное копирование: Изучим цепочки создания бэкапов: полные, дифференциальные и журналы транзакций (для модели восстановления Full в MS SQL) с обязательной периодической проверкой целостности и тестовым восстановлением.

Шаг 6. Выбор СУБД и инструменты диагностики

В современных реалиях востребованы две СУБД: Microsoft SQL Server и PostgreSQL. Принципы логического моделирования, индексирования и анализа планов в них похожи, поэтому знание базовых концепций позволяет легко переключаться между ними.

Рассмотрим специфику и набор диагностических утилит:

1. PostgreSQL: Для работы с платформой 1С используется специализированная сборка с патчами. Особое внимание уделим параметрам shared_buffers, work_mem и агрессивности работы процесса autovacuum для своевременной очистки «раздувания» (bloat) таблиц.
2. Технологический журнал 1С: Настроим сбор событий DBMSSQL / DBPGSQL для перехвата длительных запросов на уровне СУБД, а также событий TLOCK и TDEADLOCK для расследования конфликтов блокировок.
3. Системный мониторинг: В MS SQL используем системные динамические представления (DMV), в частности sys.dm_os_wait_stats, для выявления природы ожиданий (дисковая подсистема, память, блокировки), а в PostgreSQL задействуем расширение pg_stat_statements.

Важное ограничение: Любые манипуляции с физической базой 1С должны производиться строго на чтение или мониторинг. Прямое изменение данных через команды INSERT, UPDATE или DELETE в обход платформы категорически запрещено, так как разрушает целостность объектных связей и итогов регистров.