Что такое кластерный индекс в 1С и как он влияет на скорость базы

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

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

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

Как устроен кластерный индекс на уровне СУБД

Когда 1С разворачивает базу на SQL Server, каждая таблица (например, табличная часть документа или регистр сведений) получает набор индексов. Кластерный индекс организует данные в виде B-дерева, листовые страницы которого содержат сами строки таблицы, отсортированные по ключу. Поэтому поиск по диапазону ключа кластерного индекса выполняется последовательным чтением соседних страниц — это самый быстрый сценарий доступа к данным.

Некластерный индекс хранит только ключевые колонки и ссылку на строку (ключ кластерного индекса). Если запрос использует некластерный индекс, СУБД сначала находит ключи, а затем обращается к кластерной структуре за остальными полями — это операция lookup, которая при большом числе строк обходится дорого. Именно поэтому выбор кластерного ключа — архитектурное решение, влияющее на все запросы к таблице.

Важно понимать, что в файловом варианте 1С понятие кластерного индекса в классическом смысле неприменимо — там платформа использует собственный формат хранения. Всё, что касается управления кластерными индексами, относится к клиент-серверному варианту работы.

Какие кластерные индексы создаёт платформа 1С

Платформа формирует индексы автоматически при создании и реструктуризации таблиц. Для справочников и документов кластерным, как правило, становится индекс по ссылке (внутреннему уникальному идентификатору объекта). Для регистров сведений кластерный индекс строится по измерениям (и периоду для периодических регистров). Для регистров накопления и бухгалтерии — по комбинации, включающей регистратор и измерения.

Ключевой нюанс: ссылка в 1С — это GUID. Если кластерный индекс построен по GUID, новые записи вставляются в случайные места B-дерева, что вызывает расщепление страниц, фрагментацию и рост журнала транзакций. Для таблиц с интенсивной вставкой это заметная проблема производительности.

Разработчик может влиять на индексирование через свойства метаданных: свойство «Индексировать» у реквизитов, ведущие измерения регистров, признак «Ведущее» у измерений регистров сведений. Эти настройки определяют состав индексов, которые платформа создаст при обновлении конфигурации.

Как проверить, какой индекс кластерный

На уровне SQL Server информацию об индексах таблицы можно получить системным запросом к представлениям sys.indexes и sys.tables. Тип индекса с признаком clustered (type = 1) и будет искомым. Для таблиц 1С имена выглядят как _Document123, _InfoRg456 и подобные — соответствие метаданным можно выяснить через функцию ПолучитьСтруктуруХраненияБазыДанных() в конфигураторе.

SELECT t.name AS TableName, i.name AS IndexName, i.type_desc FROM sys.indexes i JOIN sys.tables t ON i.object_id = t.object_id WHERE i.type = 1 ORDER BY t.name;

Дополнительно полезно посмотреть фрагментацию индексов через sys.dm_db_index_physical_stats. Если фрагментация кластерного индекса большой таблицы существенно превышает 30%, это кандидат на перестроение (rebuild), а не на смену ключа. План запроса в SQL Server Management Studio покажет, какие индексы реально используются при выполнении проблемных запросов.

Когда стоит менять кластерный индекс

Ручная смена кластерного индекса — крайняя мера, оправданная только при доказанной проблеме. Типичный сценарий: огромный регистр сведений или накопления с интенсивной записью, где кластерный ключ по GUID-регистратору вызывает постоянную фрагментацию, а основные запросы читают данные по периоду и измерениям. Перенос кластерного индекса на комбинацию «период + измерения» может кардинально ускорить и запись, и чтение.

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

Как безопасно изменить кластерный индекс

Изменение выполняется на уровне СУБД: существующий кластерный индекс удаляется, создаётся новый с нужным ключом. Операция на большой таблице ресурсоёмкая — фактически это полная перестройка данных. Выполнять её нужно вне рабочего времени, при наличии свежей резервной копии и достаточного места в журнале транзакций и tempdb.

1. 1
   Сделайте полную резервную копию базы и проверьте её восстановление на тестовой копии
2. 2
   Определите таблицу и текущий кластерный индекс, зафиксируйте метрики: длительность запросов, фрагментацию
3. 3
   На тестовой копии создайте новый кластерный индекс и удалите старый
4. 4
   Прогоните типовые запросы и проведение документов, сравните планы и время выполнения
5. 5
   При подтверждённом эффекте повторите операцию на рабочей базе в окно обслуживания
6. 6
   Зафиксируйте изменение в документации: обновления конфигурации не должны его затереть

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

Типичные ошибки и ограничения

Отдельное ограничение: кластерный ключ должен быть по возможности узким, уникальным и статичным. Если ключ не уникален, SQL Server добавляет скрытый уникализатор, увеличивая размер. Если значения ключа часто обновляются, СУБД вынуждена физически перемещать строки — это дорогая операция, сравнимая с удалением и вставкой.

Также помните, что оптимизация индексов не заменяет работу с самими запросами и конфигурацией. Медленный запрос с неявными преобразованиями типов или сканированием таблицы не ускорится от смены кластерного ключа — сначала нужно смотреть план выполнения.

Как проверить результат после изменений

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

Частые вопросы о кластерных индексах в 1С