Лишние индексы в базе 1С на PostgreSQL: как найти, какой реквизит их создал, и как убрать

В PostgreSQL таблицы базы 1С называются _document62 и _inforg235, а индексы - _document62_5 и _inforg235_4. Администратор СУБД видит индекс, которым никто не пользуется, и не знает, какой реквизит в конфигурации его создал. Разработчик 1С знает реквизиты, но не видит, сколько раз к индексу обращались. Я написала утилиту на Python, которая сводит эти два взгляда вместе: берёт статистику PostgreSQL, описание хранения базы из платформы и выгрузку конфигурации и по каждому подозрительному индексу называет объект 1С и свойство «Индексировать», от которого он появился.

Проверила я её на учебной конфигурации «Нано-УТ» на сервере 1С 8.3.27 и PostgreSQL 17.10. Утилита нашла индексы без единого обращения, дубль, который я создала вручную, и два индекса, которые целиком покрываются другими. Потом я сняла свойство «Индексировать» в конфигурации, обновила базу и посмотрела, что сделала платформа. Все цифры в статье получены на моём стенде 22 октября 2026 года.

На Инфостарте про индексы в 1С уже писали: есть обработка «Структура базы на PostgreSQL», обработка «Структура хранения данных и рекомендации по индексам» и заметка о восстановлении индексов СУБД (ссылки в разделе «Источники»). Моя утилита отличается тем, что связывает счётчики обращений с флагами конфигурации и отдельно ищет индексы, которые повторяют уже существующие.

Стенд

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

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

В базе стенда 227 индексов, из них 176 платформа создала с признаком UNIQUE. Ключ индекса - это список колонок, по которым он упорядочен. Объявить свой индекс уникальным платформа может потому, что последней колонкой ставит в ключ ссылку на объект (_IDRRef), а она у каждой строки своя. Ту же уникальность ссылки уже обеспечивает первичный ключ, поэтому такой UNIQUE не отклонит ни одной строки, которую не отклонил бы он. Признак UNIQUE у служебного индекса 1С поэтому не помогает отличить индекс, который защищает данные, от индекса только для поиска, и утилита на него не опирается. Первичный ключ платформа создаёт как ограничение PRIMARY KEY: _document62ng_pkey. Для документа «ПродажаТовара» в исходной базе три служебных индекса по номеру и дате:

Лишние индексы появляются, когда у реквизита включено свойство «Индексировать» или «Индексировать с доп. упорядочиванием». Я включила его у пяти реквизитов документа «ПродажаТовара» (Контрагент, Склад с доп. упорядочиванием, ВидЦены, Заказ, Комментарий) и у двух измерений регистра сведений «ЦеныНоменклатуры», обновила конфигурацию базы и запустила нагрузку: 120 продаж и 30 повторов типовых запросов (документы за период, остатки на дату, документы одного контрагента). Платформа создала пять новых индексов на документе и два на регистре, а индекс _document62_3 пересоздала с добавлением склада в ключ. На рисунке показаны индексы документа и число обращений к каждому после нагрузки. Выгрузка сделана запросом collect_indexes.sql из архива; команда PowerShell на снимке читает файл-выгрузку со стенда от 22.10.2026.

Индекс _document62_4 (контрагент) использован 30 раз: на нём держится запрос «документы контрагента». Индексы по складу с упорядочиванием, виду цены, заказу и комментарию не использованы ни разу. К таблице регистра _inforg235 обращений нет совсем: ни один запрос нагрузки не читал цены.

Статистика PostgreSQL и её окно

Число обращений к индексу PostgreSQL ведёт сам. Оно лежит в представлении pg_stat_user_indexes, в поле idx_scan (от английского index scan, «просмотр индекса»):

1
2
3
4

SELECT indexrelname, idx_scan, pg_size_pretty(pg_relation_size(indexrelid))
  FROM pg_stat_user_indexes
 WHERE relname = '_document62'
 ORDER BY indexrelname;

Счётчик копится с момента, когда статистику последний раз сбрасывали. Эту дату хранит pg_stat_database.stats_reset, и утилита печатает её в начале отчёта. Перед нагрузкой я вызвала pg_stat_reset(), поэтому окно наблюдения здесь - один прогон. В рабочей базе окно должно покрывать и самые редкие отчёты: квартальные и годовые.

Что именно увеличивает счётчик, я проверила отдельным опытом на том же PostgreSQL 17.10 (скрипт queries/idx_scan_check.sql в архиве). Одна таблица на 200 000 строк, один индекс, после каждого обращения печатаются план и счётчик. idx_scan вырос при поиске по битовой карте (Bitmap Index Scan), при поиске только по индексу (Index Only Scan), при сортировке по индексу без условия и даже тогда, когда планировщик только оценивал запрос (EXPLAIN без выполнения) со значением за пределами собранной статистики: в этом случае он сам заглядывает в индекс. Значит, ноль в idx_scan означает, что за время наблюдения к индексу не обращался никто, включая планировщик.

При этом ноль - только повод разобраться. Счётчики обнуляются не только по pg_stat_reset(): PostgreSQL сбрасывает их после аварийной остановки и после восстановления из резервной копии. На стенде я это видела сама: после того как Docker был остановлен без корректного завершения, контейнер прошёл восстановление, и все счётчики базы стали нулевыми. Чтения на реплике в счётчиках основного сервера не видны: у реплики своя статистика. Индекс может быть нужен и без единого поиска, если на нём держится ограничение (UNIQUE, внешний ключ). Наконец, планировщик пользуется индексом для оценок, поэтому после удаления индекса планы других запросов могут измениться.

Связь индексов с метаданными 1С

Имена _Document62 и _Fld124RRef выдаёт платформа. Соответствие между ними и объектами конфигурации возвращает встроенная функция ПолучитьСтруктуруХраненияБазыДанных: таблица значений с именами таблиц, полей и индексов платформы. Я сохраняю её в текст из серверного модуля:

1
2
3
4
5
6
7
8
9
10

Структура = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого Таблица Из Структура Цикл
	Строки.Добавить("T" + Т + Таблица.ИмяТаблицыХранения + Т + Таблица.Метаданные + Т + Таблица.Назначение);
	Для Каждого Поле Из Таблица.Поля Цикл
		Строки.Добавить("F" + Т + Таблица.ИмяТаблицыХранения + Т + Поле.ИмяПоляХранения + Т + Поле.ИмяПоля + Т + Поле.Метаданные);
	КонецЦикла;
	Для Каждого Индекс Из Таблица.Индексы Цикл
		// Индекс.Поля - поля ключа в порядке индекса
	КонецЦикла;
КонецЦикла;

Полный модуль лежит в архиве (1c/StorageStructure.bsl); платформа проверила его командой проверки модулей, а вызов из внешнего соединения я выполнила на стенде. В выгрузке видно, что _Fld124RRef - реквизит «Склад», _Document62 - «Документ.ПродажаТовара», а индекс _Document62_5 платформа создала сама. У служебных колонок вроде _NumberPrefix в структуре нет ни имени, ни метаданных, и утилита показывает их по имени колонки.

Таблиц, которых нет в структуре (v8users, binarydata и другие служебные таблицы платформы), в базе стенда от 166 до 170 индексов. К метаданным конфигурации они не относятся, поэтому утилита сворачивает их в одну строку отчёта.

Чтобы назвать само свойство, утилита читает XML-выгрузку конфигурации (Конфигуратор, «Выгрузить конфигурацию в файлы») и берёт значения Indexing у реквизитов, измерений и ресурсов. Путь метаданных в выгрузке и в структуре хранения строится одинаково, так что поле «Склад» документа находится по строке Документ.ПродажаТовара.Реквизит.Склад.

Прогон утилиты на базе с лишними индексами

Нужны две команды: первая выгружает индексы через psql, вторая строит отчёт. Утилита ничего не меняет в базе, она только читает файлы.

python index_auditor.py collect --psql "docker exec -i -u postgres nopik-pg psql -d idxaudit" --out indexes.tsv
python index_auditor.py audit --indexes indexes.tsv --storage storage.tsv --config-dir cf-over

На снимке утилита запущена на выгрузках со стенда от 22.10.2026, которые лежат в архиве (examples). Показаны первые 30 строк отчёта.

В разделе про индексы с включённым «Индексировать» восемь индексов, 176 КБ: четыре на документе (_document62_5, _6, _7, _8) и четыре на регистре цен. Часть индексов регистра платформа создаёт и без флагов (_inforg235_1 и _3 были в исходной базе), поэтому утилита пишет осторожно: «в ключе есть поля с включённым свойством», а решение по каждому принимает человек. Индексы _document62_6, _7 и _8 существуют только из-за флагов у реквизитов ВидЦены, Заказ и Комментарий, и к ним никто не обращался.

Индексы, которые повторяют уже существующие

В базе стенда платформа не создала ни одного дубля. Дубли появляются, когда администратор добавляет индекс вручную. Я добавила в базу три индекса командой CREATE INDEX в psql:

• manual_sklad_dup с тем же ключом, что у _document62_5 (склад, дата, ссылка, пометка удаления);
• manual_sklad_prefix только по складу;
• manual_kontr_prefix только по контрагенту.

Первый из них - точная копия служебного индекса 1С. Два других тоже лишние, хотя ни с чем не совпадают. Индекс похож на телефонный справочник: если справочник отсортирован по фамилии, а внутри фамилии по имени, то искать в нём просто по фамилии так же быстро. Отдельный справочник «только по фамилиям» ничего не добавляет. Служебный индекс _document62_5 отсортирован сначала по складу, поэтому поиск по складу он уже обслуживает, и ручной индекс по складу его только повторяет. Так же ручной индекс по контрагенту повторяет начало служебного _document62_4, где контрагент стоит первой колонкой.

Оговорка: короткий индекс меньше длинного, и для части запросов PostgreSQL может выбрать именно его, например при низкой избирательности условия или для сортировки только по складу. Поэтому утилита называет такой индекс кандидатом на удаление, а решает человек. Перед удалением посмотрите планы типовых запросов (EXPLAIN) с ним и без него, лучше на копии базы.

Из пары одинаковых индексов утилита оставляет тот, который есть в структуре хранения 1С, и называет лишним чужой. Порядок колонок утилита учитывает: ключ (b, a) началом ключа (a, b, c) не считается, это проверяет тест. Индексы с условием WHERE, индексы по выражениям и индексы не вида btree утилита не сравнивает. Уникальные индексы и индексы под ограничениями утилита в кандидаты не включает, даже если они повторяют начало другого. Лишними они бывать могут, например UNIQUE поверх первичного ключа с тем же ключом, но удаление такого индекса меняет правила для данных, и решать это должен человек.

Как убрать лишнее: свойство вместо DROP INDEX

Индекс, который создала платформа, правильно убирать так: снять свойство «Индексировать» и обновить конфигурацию базы. Иначе платформа создаст его снова при следующей реструктуризации. Ручной индекс, созданный администратором вне 1С, убирают обычной командой DROP INDEX: его нет в структуре хранения, и платформа о нём не знает. Ручные индексы бывают и полезны, когда для нужного запроса платформа индекс не строит. Я загрузила в базу конфигурацию без флагов и посмотрела индексы. Снимок сделан сразу после загрузки: сверху ответ Конфигуратора, снизу запрос в psql.

Платформа пересоздала таблицу _document62 целиком: имя ограничения первичного ключа изменилось (_document62ng_pkey1 снова стало _document62ng_pkey), и все три индекса, которые я добавила вручную, исчезли вместе со старой таблицей. Это результат моего стенда: здесь платформа пересоздала таблицу. Пересоздаёт ли она таблицу при другом изменении структуры, зависит от изменения, и ручные индексы при этом могут как пропасть, так и остаться. После каждого обновления конфигурации проверяйте, на месте ли ваши ручные индексы.

Счётчики idx_scan у новой таблицы начались с нуля: окно наблюдения для неё открылось заново.

Времена двух прогонов нагрузки, 225,6 и 679,7 с, сравнивать нельзя: второй прогон шёл в базе, где уже были проведённые документы, а проведение в «Нано-УТ» дорожает по мере роста истории документов.

Цена лишних индексов на запись

Чтобы не ссылаться на общие слова, я отдельно измерила стоимость индексов без 1С, на таблице в той же СУБД. В таблицу вставляется 300 000 строк, затем обновляется 100 000 строк по колонке без индекса и ещё 100 000 строк по колонке с индексом. Опыт идёт на таблице с 0, 2, 4 и 8 дополнительными индексами. Кроме времени я смотрела на объём журнала предзаписи (WAL, от английского write-ahead log): в него PostgreSQL сначала записывает каждое изменение, чтобы не потерять его при сбое, и каждый дополнительный индекс увеличивает этот журнал. Ниже медианы трёх прогонов:

С восемью дополнительными индексами вставка заняла 19 061 мс против 3114 мс без них, то есть в шесть раз дольше, а журнал WAL вырос в 4,8 раза. Разброс на рабочем компьютере большой: в предыдущей серии из трёх прогонов тех же запросов медианы вставки были 3873 и 15 947 мс, то есть в 4,1 раза. Поэтому я пишу диапазон: в четыре-шесть раз дольше. Объём WAL в обеих сериях получился одинаковым с точностью до процентов (47,3 и 47,1 МБ без индексов, 227,7 и 228,0 МБ с восемью). Обновление колонки без индекса тоже подорожало (996 против 3265 мс); причину я не выясняла.

Отдельно я проверила оптимизацию HOT (Heap-Only Tuples). Когда обновляется колонка, которой нет в индексах, PostgreSQL может положить новую версию строки на ту же страницу таблицы и не трогать индексы. В опыте после обновления колонки без индекса 4281 из 10 000 обновлений прошли как HOT, а после обновления колонки с индексом HOT не было ни одного. Скрипты опытов лежат в архиве.

Эти цифры относятся к таблице без 1С. Стоимость проведения документов в 1С они не показывают: для этого нужен замер на вашей базе до и после снятия свойства.

Что не проверялось

• Рабочая база с миллионами строк и обычной нагрузкой; индексы на сотни мегабайт.
• PostgreSQL 15 и 16, Linux, реплики (статистика на реплике своя), секционирование.
• Конфигурации с расширениями и типовые конфигурации: у них своя структура индексов и своё поведение при перестройке таблиц.
• Платформа ниже 8.3.27.
• Влияние снятия свойства на планы запросов: утилита этого не оценивает.

Итог

Индекс без обращений - только повод разобраться. Если его создала платформа, удалять его командой СУБД нельзя: убирать его надо свойством «Индексировать» в конфигурации. Ручной индекс удаляют командой DROP INDEX, проверив планы запросов. На стенде утилита нашла четыре индекса документа без обращений, ручной дубль и два ручных индекса, которые повторяют начало служебных. После снятия флагов платформа вернула таблицу к трём служебным индексам, а данные и результаты запросов остались прежними. Перед снятием свойства проверьте, за какой срок накоплена статистика, и запустите редкие отчёты на копии базы.

Источники

• PostgreSQL 17, представления статистики pg_stat_all_indexes и pg_stat_user_indexes
• PostgreSQL 17, многоколонночные индексы и порядок колонок
• PostgreSQL 17, HOT-обновления (Heap-Only Tuples)
• Infostart, «Структура базы на PostgreSQL» (соответствие метаданных и таблиц, размеры индексов)
• Infostart, «Структура хранения данных и рекомендации по индексам» (размер таблиц и индексов, статистика, неиспользуемые индексы)
• Infostart, «Восстановление индексов СУБД» (создание индексов по структуре хранения базы 1С)

Файл к статье

Архив postgresql-index-audit-companion.zip (стенд от 22.10.2026):

• index_auditor.py - утилита, команды collect и audit, только стандартная библиотека Python;
• queries/collect_indexes.sql - выгрузка индексов со статистикой; bench_write_cost.sql и hot_update_check.sql - опыты на PostgreSQL;
• 1c/StorageStructure.bsl - выгрузка структуры хранения базы 1С;
• examples - выгрузки со стенда (три состояния базы) и файлы конфигурации с флагами; verify.py и test_index_auditor.py - 15 тестов логики и 15 проверок на выгрузках;
• stand - модуль стенда, нагрузка, вариант конфигурации с лишними индексами; evidence - журналы прогона.

Архив проверен из чистой распаковки: python verify.py проходит без базы и платформы. README.md описывает порядок работы с вашей базой.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S