Медленный поиск в базе 1С 8.3: где теряется время и что с этим делать

Чтобы ускорить поиск в 1С, сначала поймите, какой поиск тормозит. Строка поиска в шапке программы работает через полнотекстовый индекс: его нужно включить и регулярно обновлять. Поиск в списке и подбор в поле ввода идут запросом к базе: тут помогают индексы реквизитов, обновлённая статистика СУБД и быстрый диск.

Типичная картина: бухгалтер вводит ИНН контрагента в список, и курсор крутится 15 секунд. Коллега в соседнем окне ищет тот же ИНН в общей строке поиска и получает ответ мгновенно. Это два разных механизма, и лечатся они по-разному. Ниже — от простых настроек пользователя до оптимизации базы и сервера.

Какой поиск тормозит: три механизма в 1С 8.3

Прежде чем что-то настраивать, определите источник задержки. В 1С 8.3 «поиск» — это минимум три разные вещи.

Пара быстрых проверок:

• 🔍 Тормозит везде и всегда — проблема в сервере, диске или СУБД.
• 🔍 Тормозит только общий поиск — индекс выключен или устарел.
• 🔍 Тормозит один список — поиск идёт по неиндексированной колонке или по всем колонкам сразу.
• 🔍 Тормозит у одного пользователя — его настройки списка или клиентский кэш.

Что пользователь может сделать сам, без прав администратора

Часть ускорения доступна любому, кто работает в базе. Ничего ломать здесь нельзя.

Ищите по колонке, а не «везде»

В форме списка в интерфейсе «Такси» поле поиска по умолчанию ищет по видимым колонкам. Если в списке 12 колонок и 300 тысяч строк, программа строит тяжёлый запрос с условием по каждой из них.

Что делать:

1. Встаньте курсором в нужную колонку (например, «ИНН» или «Номер»).
2. Откройте расширенный поиск: Alt+F или команда Еще → Расширенный поиск.
3. Выберите поле и вариант сравнения «Совпадает» или «Начинается с».

Поиск по точному совпадению или по началу строки СУБД умеет выполнять по индексу. Поиск «по любой части строки» вынуждает её просматривать таблицу целиком.

Сократите выборку отбором и периодом

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

Уберите лишние колонки и сбросьте настройки списка

Каждая добавленная колонка из связанного объекта (например, «Контрагент.ИНН» в списке документов) — это дополнительное соединение таблиц. Если список «пересобирали» годами, верните его к исходному виду: Еще → Изменить форму → Стандартные настройки в окне настройки формы.

Полнотекстовый поиск: включить и поддерживать индекс

Общая строка поиска в типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) использует полнотекстовый индекс. Он хранит слова из данных базы и находит их без перебора таблиц.

Где включается: Администрирование → Общие настройки, блок про полнотекстовый поиск. Там есть флажок использования и команда настройки, где видна дата актуальности индекса и кнопки обновления.

Индекс поддерживают два регламентных задания:

• ⚙️ Обновление индекса полнотекстового поиска — добавляет в индекс новые и изменённые данные. Обычно запускается часто, раз в несколько минут.
• ⚙️ Слияние индекса полнотекстового поиска — объединяет накопленные порции в основной индекс. Обычно раз в сутки, ночью.

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

Когда индекс нужно перестроить с нуля

Признаки: поиск перестал находить заведомо существующие данные, падает с ошибкой или папка индекса разрослась несоразмерно базе. Тогда:

1. Отключите полнотекстовый поиск в настройках.
2. В файловой базе закройте все сеансы и удалите папку 1Cv8FTxt из каталога базы. В клиент-серверной базе индекс лежит в каталоге информационной базы на сервере 1С; удалять его там можно только при остановленной работе с базой.
3. Включите поиск снова и запустите полное обновление индекса.

Полное построение индекса на базе в десятки гигабайт идёт часами. Запускайте вечером.

Индексы на уровне СУБД: реиндексация и статистика

Для клиент-серверной базы на MS SQL Server или PostgreSQL скорость поиска в списках решает СУБД. Две вещи важнее всего: состояние индексов и актуальность статистики.

Обновление статистики

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

Для MS SQL Server обновление статистики и очистка кэша планов:

USE [имя_базы];
EXEC sp_updatestats;
-- после обновления статистики сбросить устаревшие планы
DBCC FREEPROCCACHE;

Для PostgreSQL:

VACUUM ANALYZE;

Обычный VACUUM ANALYZE не блокирует работу пользователей. А вот VACUUM FULL блокирует таблицы — его запускайте только в окно обслуживания.

Перестроение индексов

Индексы фрагментируются по мере записи данных. В MS SQL Server настройте план обслуживания: ежедневно — обновление статистики, еженедельно — реорганизация или перестроение индексов. Ориентир, который обычно используют администраторы: реорганизация при фрагментации от 5–10% до 30%, перестроение — выше 30%.

Без доступа к СУБД можно запустить средство самой 1С: Конфигуратор → Администрирование → Тестирование и исправление, флажок «Реиндексация таблиц информационной базы».

Почему не стоит добавлять свои индексы прямо в SQL

Хочется создать индекс в Management Studio на нужное поле. Так делать не стоит: при реструктуризации таблиц (обновление конфигурации) платформа пересоздаёт их по своим правилам, и ваш индекс пропадёт. Хуже — он может помешать реструктуризации. Индекс правильно задавать в метаданных конфигурации.

Индексы реквизитов и запросы в конфигураторе

Здесь работа для программиста 1С.

Свойство «Индексировать» у реквизита

Если пользователи регулярно ищут по реквизиту, который не индексируется (например, по номеру входящего документа или по артикулу), откройте реквизит в конфигураторе и задайте свойство «Индексировать»:

• Индексировать — индекс по одному полю, ускоряет поиск по точному значению и началу строки.
• Индексировать с доп. упорядочиванием — индекс вместе с полем упорядочивания; полезно, когда список и ищут, и сортируют по этому полю.

Каждый индекс замедляет запись и увеличивает базу. Индексируйте только то, по чему реально ищут.

Изменение свойства реквизита — это изменение основной конфигурации. Для типовой на поддержке оно усложнит обновления: учитывайте это до правки.

Как писать запросы для быстрого поиска

Разработчик чаще всего замедляет поиск одними и теми же приёмами. Что исправлять:

• 🐢 ПОДОБНО с процентом в начале (ПОДОБНО "%текст%") не использует индекс. Если по смыслу подходит поиск по началу строки — пишите ПОДОБНО "текст%".
• 🐢 Условия в ГДЕ вместо параметров виртуальной таблицы. Для Остатки и ОстаткиИОбороты отбор передавайте в параметрах таблицы, иначе сначала считаются итоги по всему регистру.
• 🐢 Цепочки через точку по составным полям. Обращение Регистратор.Контрагент к полю составного типа порождает соединения со всеми возможными таблицами. Помогает ВЫРАЗИТЬ(Регистратор КАК Документ.РеализацияТоваровУслуг).Контрагент.
• 🐢 Запрос в цикле. Сто запросов по одному элементу медленнее одного запроса со списком в параметре В (&Список).
• 🐢 Соединение с подзапросом. Подзапрос лучше вынести во временную таблицу и проиндексировать по полю соединения.

Пример выноса отбора во временную таблицу с индексом:

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|	Контрагенты.Ссылка КАК Ссылка
|ПОМЕСТИТЬ ВТКонтрагенты
|ИЗ
|	Справочник.Контрагенты КАК Контрагенты
|ГДЕ
|	Контрагенты.ИНН = &ИНН
|ИНДЕКСИРОВАТЬ ПО
|	Ссылка
|;
|ВЫБРАТЬ
|	Реализация.Ссылка КАК Документ,
|	Реализация.Дата КАК Дата
|ИЗ
|	Документ.РеализацияТоваровУслуг КАК Реализация
|		ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТКонтрагенты КАК ВТ
|		ПО Реализация.Контрагент = ВТ.Ссылка";
Запрос.УстановитьПараметр("ИНН", "7700000000");
Результат = Запрос.Выполнить().Выгрузить();

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

Железо: диск, память, процессор

Никакая настройка не спасёт базу на перегруженном HDD.

Пара практических замечаний:

• 💾 Файловая база. Если база лежит в сетевой папке, каждый поиск тянет данные по сети. На 5–10 и более одновременных пользователях файловая база упирается в блокировки и диск — это сигнал переходить на клиент-серверный вариант.
• 💾 MS SQL Server. Ограничьте максимальную память SQL Server так, чтобы осталось место системе и рабочим процессам 1С, если они на одной машине. Иначе сервер начнёт выгружать память на диск.
• 💾 Антивирус. Исключите из проверки каталоги баз, файлов СУБД и кэша сервера 1С. Проверка «на лету» каждого чтения файла базы замедляет любые операции.

Кэш сервера 1С и клиента

Платформа кэширует метаданные и данные сеансов. Иногда кэш, наоборот, мешает.

Клиентский кэш

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

"C:\Program Files\1cv8\common\1cestart.exe" /ClearCache

Пользователь при этом должен быть вне базы. Данные базы не затрагиваются.

Серверный кэш

Кэш сервера хранится в каталоге кластера (srvinfo\reg_1541) в папках сеансовых данных и временных файлов. Его чистку применяют, когда сервер после сбоя или обновления работает заметно медленнее.

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

Внешние поисковые системы

Встроенный полнотекстовый поиск 1С ищет по словам и их формам, но не умеет нечёткий поиск по опечаткам, ранжирование по релевантности на уровне поисковых систем и поиск по содержимому миллионов приложенных файлов.

Когда этого не хватает, данные выгружают во внешнюю поисковую систему — например, Elasticsearch или OpenSearch:

1. 1С выгружает изменённые объекты по регламентному заданию или через HTTP-сервис.
2. Поисковая система индексирует их и отвечает на запросы.
3. Результат поиска возвращает ссылку на объект 1С, который пользователь открывает обычным способом.

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

Регламентное обслуживание: чтобы поиск не замедлялся снова

Разовая оптимизация через полгода сойдёт на нет без регулярного обслуживания.

Ещё две меры, о которых часто забывают:

• 🧹 Удаление помеченных объектов. Помеченные на удаление элементы продолжают участвовать в поиске и раздувать таблицы.
• 🧹 Свёртка или архивирование старых периодов. Если база хранит 10 лет учёта, а работают с последними двумя, разделение базы уменьшает объём таблиц, по которым идёт поиск. Решение серьёзное, обсуждайте его с бухгалтерией и делайте на копии.

Частые вопросы