При работе с крупными справочниками в системе «1С:Предприятие 8.3», объем которых достигает 500 000 и более записей, пользователи часто сталкиваются с существенным замедлением поиска. Ситуация осложняется, когда в конфигурации активно используется механизм RLS (Record Level Security) — ограничение доступа на уровне записей. В данной статье мы детально разберем, поможет ли введение дополнительного реквизита ускорить поиск, почему стандартные фильтры начинают «тормозить» и какие альтернативные методы оптимизации существуют.
Рассмотрим ситуацию: поиск ведется по части наименования (например, поиск строки «2017» внутри строки «Договор №117... за 2017 год»). Для СУБД такой запрос транслируется в конструкцию LIKE '%2017%'. Проанализируем, что происходит на уровне базы данных:
%...), SQL-сервер не может использовать индекс по полю Наименование. Ему приходится прочитать все 500 000 записей.WHERE EXISTS....Разберем идею создания дополнительного реквизита типа Число(4,0) для хранения года. Поможет ли это? Проанализируем структуру хранения дополнительных реквизитов в типовых конфигурациях (БСП):
Дополнительные реквизиты хранятся не в основной таблице справочника, а в табличной части ДополнительныеРеквизиты (или в отдельном регистре сведений, в зависимости от версии БСП). Поиск по такому реквизиту означает выполнение соединения (JOIN) основной таблицы с подчиненной таблицей значений свойств.
Преимущества:
Недостатки:
Полнотекстовый поиск — это встроенный механизм платформы 1С, который создает отдельные индексы для быстрого нахождения слов и чисел в любых данных. Выясним причины, по которым он может работать медленно или не работать вовсе:
ОбновлениеИндексаППД.Проанализируем ситуацию, когда расширения и изменение кода запрещены. В этом случае мы можем использовать административные настройки:
1. Настройка формы списка:
Выведите дополнительный реквизит «Год» в колонку списка. При использовании стандартного поиска (Ctrl+F) приучите пользователей выбирать режим «Искать в: [Наметка на колонку]» и «Соответствие: Целиком». Это заставит систему выполнять поиск по конкретному полю, что значительно быстрее «общего поиска по всем полям».
2. Использование отборов:
Вместо «поиска» (который часто работает как фильтр по подстроке) используйте «Настроить список». Условие отбора ДополнительныйРеквизит.Год Равно 2017 на уровне платформы отрабатывает эффективнее, так как система более оптимально строит SQL-запрос.
3. Свертка и пометки на удаление:
Проверьте, сколько записей в справочнике помечены на удаление. Если их много, установите постоянный отбор в списке ПометкаУдаления Равно Ложь. Это уменьшит объем данных, которые СУБД приходится обрабатывать при каждом поиске.
Если бы у нас была возможность программной коррекции, мы бы использовали запрос к таблице дополнительных сведений. Рассмотрим пример того, как система ищет данные по доп. реквизиту:
// Пример запроса, который система строит неявно при поиске по доп. реквизиту
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Договоры.Ссылка КАК Ссылка
|ИЗ
| Справочник.ДоговорыКонтрагентов КАК Договоры
| ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ДоговорыКонтрагентов.ДополнительныеРеквизиты КАК ДопРеквизиты
| ПО Договоры.Ссылка = ДопРеквизиты.Ссылка
|ГДЕ
| ДопРеквизиты.Свойство = &СвойствоГод
| И ДопРеквизиты.Значение = &ЗначениеГод";
Запрос.УстановитьПараметр("СвойствоГод", СсылкаНаСвойствоГод);
Запрос.УстановитьПараметр("ЗначениеГод", 2017);
Обратите внимание: если свойство СвойствоГод проиндексировано в метаданных табличной части, поиск будет выполняться быстро. Но наличие RLS добавит в этот запрос еще несколько соединений с таблицами прав доступа, что и является основной «ценой» безопасности.
Подведем итог нашему анализу: