Индексирование в 1с что это
Индекс (англ. index) — объект базы данных, создаваемый с целью повышения производительности поиска данных. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному критерию путём последовательного просмотра таблицы строка за строкой может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы и, таким образом, позволяет искать строки, удовлетворяющие критерию поиска. Ускорение работы с использованием индексов достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск — например, сбалансированного дерева.
Если простым языком индекс похож на содержание книги, когда вам надо найти что-то в книге у вас два варианта:
1. Если содержания нет - просмотреть всю книгу с первой по последнюю страницу в поисках нужной главы. Повторять это для каждого запроса.
2. Зайти в содержание (индекс), найти быстро номер страницу нужной главы (адрес). Перейти на нужную страницу.
Понятно что второй способ занимает, особенно если книга большая*, намного меньше времени. А если повторять это многократно то время экономится глобально (читай - ресурсы сервера).
* - Важно! Если книга очень маленькая, то использование содержания (индекса) становится бесполезным и даже вредным, проще просмотреть две страницы и сразу выяснить искомую главу.
Как выглядят индексы в базе 1С
В файловом режим базы данных (*.1cd) индексы не увидишь, а вот если база в клиент-серверном варианте, то индексы выглядят в консоли СУБД примерно так:
Как добавить индексы в 1С
В базу 1С индексы могут быть добавлены двумя способами:
1. Платформой автоматически. Независимо от действий программиста, при создании объектов метаданных в дереве (справочники, документы, регистры), одновременно с созданием в БД соотвествущей таблицы (таблиц), платформа создает и индексы для этих таблиц.
2. Явным указанием программиста. Программист может частично управлять созданием индекса, в "свойствах" реквизита для этого выделен специальный элемент "индексировать":
Конкретно в этом случае не используется разделение данных и ОРРХ | ОРНР1 не будет. Значит будет создан индекс "Реквизит + Ссылка", включающий в себя целевой реквизит "вид номенклатуры" и еще колонку "ссылка", составной индекс по двум полям таблицы.
Справка 1С:
Кроме варианта "Индексировать" в данном свойстве для большинства объектов можно установить вариант "Индексировать с доп. упорядочиванием". Данный вариант предназначен, прежде всего, для использования в динамических списках.
В варианте "Индексировать" строится индекс непосредственно по реквизиту. Индекс также дополняется ссылкой, чтобы обеспечить определенный порядок записей в индексе при повторяющихся значениях реквизита.
В варианте "Индексировать с доп. упорядочиванием" индекс строится по реквизиту, а также по некоторому полю, которое обычно используется для упорядочивания объектов этого типа. Для справочника индекс в зависимости от основного представления дополняется кодом или наименованием. А для документа, индекс дополняется датой. Этот индекс также дополняется ссылкой.
Таким образом при определении варианта свойства Индексировать следует исходить из того, какие варианты выборки информации необходимо оптимизировать в первую очередь. Например, если требуется просмотр списка с отбором по реквизиту, то имеем смысл использовать вариант "Индексировать с доп. упорядочиванием". А если индекс нужен, например, только для поиска с помощью запроса объектов по данному реквизиту без упорядочивания, то лучше использовать вариант "Индексировать", чтобы создаваемые индекс требовал меньше ресурсов системы.
Есть еще один способ явно указать платформе что надо создать индекс, необходимо этот реквизит справочника включить в какой-нибудь "критерий отбора".
Есть еще один способ - добавить индекс в вашем запросе, используется для временных таблиц. Во время написания запроса пишем "ИНДЕКСИРОВАТЬ ПО" после которого перечислить поля, по которым нужно построить индекс. Например:
Поля, по которым происходит индексирование, должны находиться в списке выборки.
Можно ли обойти ограничения платформы по индексам
Ограничение платформы - 1С сама добавляет к вашему индексу дополнительные колонки, т.е. делает его составным. А вот если вы решили сделать составной индекс из нескольких реквизитов, то эта возможность наоборот отсутствует.
Частично можно обойти ограничение следующим образом. Вычислить имя таблицы, есть обработки которые показывают настоящие имена таблиц, создать запрос создания индекса, примерно такой:
Выполняем его в консоли СУБД, готово индекс добавлен и будет работать.
Есть проблема, при реструктуризации базы данных (например после изменения справочника) все те индексы, что Вы создадите скриптами самостоятельно будут удалены. Вам потребуется заново запустить эти скрипты после реструктуризации, например, добавив их в Jobs на сервере СУБД на ежедневный запуск.
Внимание! Прежде чем лепить свои индексы попробуй оптимизировать код запроса средствами 1С, возможно одно добавленное условие, или смена порядка, приведет к "попаданию в индекс" и запрос ускорится в разы! Также не забывай что у тебя есть способ указать для реквизита "индексировать".
Как обслуживать индексы в базе 1С
А надо что-то делать? Ведь индексы уже созданы автоматически? Да, надо. Необходимо еженедельно\ежедневно и в некоторых случая частично ежечасно обновлять данные в индексах, чтобы они работали действительно эффективно. Для этого существуют стандартные команды обновления и\или перестроения индекса которые необходимо отправлять СУБД. Как правило для этого создают регламентную работу на сервере СУБД и она выполняется автоматически.
В MSSQL это можно сделать одной мышью в "планах обслуживания" - создаем задачу, указываем базу - готово. Выглядит примерно так.
Штатная реиндексация в 1С
В конфигураторе через меню Администрирование - Тестирование и исправление, можно попасть в форму где можно выбрать работу по реиндексации текущей базы.
Для измерений, реквизитов и т.д. применяются условные имена Измерение1, Реквизит1 и т.д.
Для общих реквизитов, являющихся разделителями в режиме "независимо", будем использовать имена ОРНР (ОРНР1, ОРНР2, и т.д.).
Для общих реквизитов, являющихся разделителями в режиме "независимо и совместно", будем использовать имена ОРСР.
Если режим разделения не имеет значения, то для общих реквизитов, являющихся разделителями, будем использовать имена ОРР.
Если в конфигурации определены разделители, то в индексы может входит поле, которое содержит значение хэш-функции набора значений разделителей. Такое поле будем обозначать именем ОРРХ.
Те индексные поля, которые не являются обязательными приведены в квадратных скобках, а если в индексе присутствует набор однотипных полей, это описывается многоточием, например: Реквизит + Измерение1 + [Измерение2 +. ].
Данным материалом следует руководствоваться при написании текстов запросов с целью оптимизации времени их исполнения.
Справочник
Основные индексы
[ОРНР1 + . +] Ссылка (Кластерный)
Всегда.
В индекс входят поля независимых разделителей, которые разделяют этот справочник.
[ОРРХ | ОРНР1 +] Код + Ссылка
Свойство "Длина кода" не равно 0.
Если справочник разделяется одним независимым разделителем, тип которого не Строка, то индекс содержит поле этого разделителя.
Если тип разделителя - Строка, или разделитель независимый и совместный, или разделителей больше одного, то индекс содержит поле значения хэш-функции значений разделителей.
Это правило справедливо для всех индексов, в составе которых указано [ОРРХ | ОРНР1 +].
[ОРРХ | ОРНР1 +] Наименование + Ссылка
Свойство "Длина наименования" не равно 0.
[ОРРХ | ОРНР1 +] Реквизит + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать".
[ОРРХ | ОРНР1 +] Реквизит + Код + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина кода" не равно 0, а свойство "Основное представление" равно "В виде кода".
[ОРРХ | ОРНР1 +] Реквизит + Наименование + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина наименования" не равно 0, а свойство "основное представление" равно "В виде наименования".
[ОРРХ | ОРНР1 +] Реквизит
Справочник включен в критерий отбора через реквизит "Реквизит".
[ОРРХ | ОРНР1 +] PredefinedID
Индекс по идентификатору предопределенного объекта метаданных.
Дополнительные индексы для подчиненного справочника (вне зависимости от иерархичности справочника)
[ОРРХ | ОРНР1 +] Владелец + Ссылка
Свойство "Длина кода" равно 0.
[ОРРХ | ОРНР1 +] Владелец + Код + Ссылка
Свойство "Длина кода" не равно 0.
[ОРРХ | ОРНР1 +] Владелец + Наименование + Ссылка
Свойство "Длина наименования" не равно 0.
[ОРРХ | ОРНР1 +] Владелец + Реквизит + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать".
[ОРРХ | ОРНР1 +] Владелец + Реквизит + Код + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина кода" не равно 0, а свойство "Основное представление" равно "В виде кода".
[ОРРХ | ОРНР1 +] Владелец + Реквизит + Наименование + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина наименования" не равно 0, а свойство "основное представление" равно "В виде наименования".
Дополнительные индексы для иерархического неподчиненного справочника
Если для справочника установлено свойство "Размещать группы сверху", то в индексах, наряду с полем Родитель, участвует поле ЭтоГруппа. Состав индексов соответствует приведенной ниже таблице.
[ОРРХ | ОРНР1 +] Родитель + ЭтоГруппа + Ссылка
Свойство "Длина кода" равно 0 и свойство "Длина наименования" равно 0.
[ОРРХ | ОРНР1 +] Родитель + ЭтоГруппа + Код + Ссылка
Свойство "Длина кода" не равно 0.
[ОРРХ | ОРНР1 +] Родитель + ЭтоГруппа + Наименование + Ссылка
Свойство "Длина наименования" не равно 0.
[ОРРХ | ОРНР1 +] Родитель + ЭтоГруппа + Реквизит + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать".
[ОРРХ | ОРНР1 +] Родитель + ЭтоГруппа + Реквизит + Код + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина кода" не равно 0, а свойство "Основное представление" равно "В виде кода".
[ОРРХ | ОРНР1 +] Родитель + ЭтоГруппа + Реквизит + Наименование + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина наименования" не равно 0, а свойство "основное представление" равно "В виде наименования".
Для справочников без размещения групп сверху состав индексов соответствует приведенной выше таблице, но в индексы при этом не включено поле ЭтоГруппа.
Дополнительные индексы для иерархического подчиненного справочника
Если для справочника установлено свойство "Размещать группы сверху", то в индексах, наряду с полем Родитель, участвует поле ЭтоГруппа. Состав индексов соответствует приведенной ниже таблице.
[ОРРХ | ОРНР1 +] Владелец + Родитель + ЭтоГруппа + Ссылка
Свойство "Длина кода" равно 0 и свойство "Длина наименования" равно 0.
[ОРРХ | ОРНР1 +] Владелец + Родитель + ЭтоГруппа + Код + Ссылка
Свойство "Длина кода" не равно 0.
[ОРРХ | ОРНР1 +] Владелец + Родитель + ЭтоГруппа + Наименование + Ссылка
Свойство "Длина наименования" не равно 0.
[ОРРХ | ОРНР1 +] Владелец + Родитель + ЭтоГруппа + Реквизит + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать".
[ОРРХ | ОРНР1 +] Владелец + Родитель + ЭтоГруппа + Реквизит + Код + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина кода" не равно 0, а свойство "Основное представление" равно "В виде кода".
[ОРРХ | ОРНР1 +] Владелец + Родитель + ЭтоГруппа + Реквизит + Наименование + Ссылка
Для реквизита "Реквизит" свойство "Индексировать" установлено в значение "Индексировать с доп. упорядочиванием" и при этом свойство "Длина наименования" не равно 0, а свойство "основное представление" равно "В виде наименования".
Для справочников без размещения групп сверху состав индексов соответствует приведенной выше таблице, но в индексы при этом не включено поле ЭтоГруппа.
Не сомневаюсь, что Вы знаете о назначении индексов и уже использовали их в повседневной работе. Разбираетесь в какой-то мере в принципе их работы, на уровне, достаточном для оптимизации запросов и создания оптимальной структуры базы данных. Прочитали множество материала по этой теме. В общем, говорите с ними на "ты".
Тема индексов относится больше к теме администрирования базы данных и поддержания стабильности и производительности ее работы. В обычном представлении, разработчик 1С не имеет к их созданию и поддержке прямого отношения. В идеальном мире эта задача ложится на плечи администратора базы данных, но его не часто встретишь в штате. Скорее всего этим занят сисадмин, по крайней мере так многие считают. А у него своих проблем хватает, поэтому он просто копипастом настраивает обслуживание и забывает про 1С.
Когда совсем приспичит, разработчики 1С начинают добавлять индексы через настройки метаданных в конфигураторе. И Вам очень повезет, если индекс будет создан корректно, т.к. часто используется инновационный метод "тыка" при их настройке.
Все это к тому, что часто эта тема проходит мимо разработчиков и администраторов. В проблемах разбираются быстро, принимая "странные" решения и советуя их другим. После этого устоявшиеся подходы становятся "правильными" и "неоспоримыми".
Сегодня мы рассмотрим несколько самых распространённых заблуждений об индексах в контексте 1С, рожденных такими устоявшимися подходами, а также постараемся их объяснить и развеять.
Почему это важно
Придется стать героем! Изучить работу СУБД, в частности индексов, и встать на светлую сторону! Жизнь информационной базы в твоих руках! Расширь горизонты познания!
От простого к невероятному
Немного пафосно было сказано, но и правда кто, если не мы?! Вся эта ситуация и создает множество заблуждений про индексы, а в последствии и ошибки при работе с ними. Давайте по порядку рассмотрим самые распространенные из них, передвигаясь от простого к сложному.
Изучение работы индексов, если Вы с ними еще не сталкивались, можно начать с помощью материалов, ссылки на которые добавлены в конце публикации. Сейчас же принципы их работы и что это вообще такое мы рассматривать не будем, тема другая.
Индексы не нужны
Часто приходилось слышать, что об индексах в базе можно не заботиться, т.к. это специфичная тема и мы так уже 15 лет живем. То есть проблем никогда не было, так зачем об этом беспокоиться? Да, у нас система жутко тормозит в периоды закрытия месяца и формирования тяжелых отчетов, но это же 1С! Просто нужно смириться или купить сервер получше. Да и вообще, нет времени с этим копаться.
Слышал такое настолько часто, что удивляюсь до сих пор. Самое обидное, что все аргументы проходят всегда мимо и не воспринимаются всерьез. Вот он, дух 1С! То что явно не сказано в инструкциях к платформе и не проверяется на сдаче экзамена "1С:Специалист по платформе", то не должно удостаиваться внимания. К счастью, такое не везде, но удручающе часто. Даже в больших компаниях.
Но индексы конечно же нужны! Это одно из самых эффективных средств повышения скорости поиска данных в базе. Без них большинство запросов выполнялось бы неприемлемое количество времени. Чем больше база, тем больше было бы это время. Если бы индексы были не нужны совсем, то, думаю, разработчики платформы не добавляли штатные кластерные индексы на большинство таблиц, не было бы настроек индексирования в объектах метаданных и многого другого. Нужно ли еще что-то говорить по этому поводу.
Индексы - это сложно
Даже если индексы и нужны, то тема эта настолько сложная, что и браться за нее не стоит! Да, это еще один миф, который довольно часто встречается на просторах разработчиков 1С и системных администраторов. И это тоже заблуждение, т.к. достаточно один раз изучить основы работы и все встанет на свои места. В большинстве случаев, индекс представляет собой некоторый эффективно организованный указатель на значения, с помощью которого поиск осуществляется значительно быстрее по сравнению с полным перебором записей в таблице. Описывать подробно принцип работы индексов здесь смысла нет, да и это уже делали не раз на Инфостарт. Оставлю здесь несколько полезных ссылок:
Прочитав даже одну лишь из перечисленных статей, Вы навсегда поймете, что индексы - это просто. Когда знаешь - все становится просто. Знание - сила!
СУБД создает индексы автоматически
Помню не одну беседу, когда мне пытались доказать, что СУБД, в т.ч. Microsoft SQL Server, создает все необходимые индексы автоматически и полностью самостоятельно на основе собранной статистики. То есть если мы много много много раз выполним какой-либо запрос и SQL Server поймет, что для его эффективной работы нужен индекс, то она создаст его!
Это, конечно же, полностью не так! Создание, изменение и удаление индексов - это обязанность разработчика баз данных или администратора БД. Автоматически СУБД ничего не создает и не удаляет, и это очень хорошо. Вы только представьте ситуацию, когда SQL Server решит создать индекс автоматически во время рабочего дня, породив блокировку данных. Или автоматически создаст пару индексов и полностью займет свободное дисковое пространство, ведь индексы имеют накладные затраты в виде занимаемого места на диске и времени на их поддержание.
Но от части это все же правда. Но не в плане, что СУБД создает индексы автоматически, а в том, что она может подсказать каких индексов сейчас не хватает. Ранее в публикациях были рассмотрены скрипты для SQL Server и PostgreSQL, среди которых были и те, что показывали отсутствующие индексы. Для SQL Server статистика по отсутствующим индексам по умолчанию собирается наиболее подробная по сравнению с данными для PostgreSQL.
Список отсутствующих индексов по результатам собранной статистики SQL Server.
Не стоит перезапускать службу SQL Server каждую ночь, иначе полезной статистики Вы не соберете, не говоря уже об остальных недостатках такого подхода.
Для PostgreSQL также можно посмотреть отсутствующие индексы, но информация не такая точная и полная как для SQL Server.
Для анализа недостающих индексов в этом случае стоит собирать информацию о тяжелых запросах и планах их выполнения, чтобы по результатам изменить структуру БД.
Не стоит уповать на СУБД в части создания индексов в автоматическом режиме. Все же думать над этим придется, а SQL Server / PostgreSQL / др. СУБД дадут эффективные инструменты анализа недостающих индексов и средства их создания и поддержки.
Платформа 1С создает все индексы сама
Как Вы уже поняли, СУБД не создает индексы автоматически, адаптируясь под выполняемые запросы. НО! Значит платформа 1С сама создает недостающие индексы для оптимизации производительности!
На самом деле, конечно же, нет. Услышав такое, можно очень удивиться и пойти пить крепкий чай. Но столкнуться с таким до сих пор можно. Тут, на самом деле, возможно, появляется путаница, ведь платформа все же создает индексы в зависимости от типа объекта метаданных и его настроек. Это действительно так и по этой ссылке Вы можете изучить все возможные платформенные индексы.
В остальных же случаях разработчику приходится самостоятельно настраивать индексирование полей, чтобы добиться нужного результата. К сожалению, искусственный интеллект в платформу еще не завезли.
Чем больше индексов, тем лучше
Для быстрого поиска нужен индекс. Так почему же не добавить индекс на каждое поле. Например, есть справочник "Номенклатура" в конфигурации "Управление торговлей" ред. 11. В нем имеется несколько индексов, большинство из которых создается платформой 1С без каких-либо особых настроек. Есть и индексы, созданные специально для тех реквизитов, в которых свойство "Индексировать" установлено в "Индексировать" (извините за тавтологию, но такие уж названия):
- Артикул
- Вид номенклатуры
- Код для поиска
Но что, если нужно выполнить поиск по реквизиту "Код ОКВЭД" или "Код ОКП"? Или любому другому полю? Почему бы не добавить индексы на каждое поле?
Да, тут сразу можно понять, что что-то не так и добавление индексов на все поля таблицы дело не самое правильное. Как уже говорилось выше, индексы имеют свои накладные расходы для обслуживания. Кроме дополнительного дискового пространства, для их поддержки СУБД тратит дополнительное время при выполнении операций модификации данных. Когда Вы изменяете запись в таблице, СУБД обновляет данные индекса, что требует дополнительного времени и ресурсов. Чем больше индексов на таблице, тем больше времени на поддержку индекса тратится. Это время может быть незначительным относительно общего времени выполнения операции записи, но чем больше индексов, тем сильнее это время будет увеличиваться.
С помощью простого запроса можно проанализировать список индексов, на поддержание которых СУБД тратит значительные ресурсы в части операций ввода / вывода.
Не обязательно, что найденные индексы нужно удалять или изменять. Иногда такие индексы могут быть нормой.
Но задуматься все же стоит. Возможно, есть необходимость переписать запросы и оптимизировать структуру используемых индексов или даже таблиц.
К сожалению, такого простого запроса для PostgreSQL нет. Там требуется другой подход.
Плюс ко всему, неизвестно какие индексы для всех полей добавлять, ведь они могут быть составными, покрывающими, а еще для использования индексов значение отбора должно быть селективным. Какой смысл искать в индексе по полю "Пометка удаления" со значением Ложь, если 99% записей в таблице не помечены на удаление? Индекс не будет использоваться, т.к. смысла искать по неселективному значению нет.
Таким образом, смысла создавать индексы для всех полей просто нет, да и для большого числа полей тоже. При создании индекса нужно точно знать для каких целей он создается, иначе он будет висеть мертвым грузом и просто "съедать" ресурсы сервера. Если уж и стоит задача поиска по всем возможным полям, то скорее всего нужен другой подход в виде полнотекстового поиска и т.д.
Главное, чтобы поле входило в индекс
Перейдем к более практическим кейсам. Еще одним частым "фейлом" можно считать ситуацию, когда разработчики считают, что для эффективной работы индекса главное наличие в нем нужно поля. Например, в типовой конфигурации "Управление торговлей" ред. 11 имеется регистр сведений "Календарные графики" со следующей структурой.
Разработчики 1С очень часто игнорируют использование конструкции «ИНДЕКСИРОВАТЬ ПО» в запросе.
Зачем нужно индексировать поля в запросе 1С 8.3, я расскажу ниже.
Как работает ИНДЕКСИРОВАТЬ ПО?
Индексация в запросе нужна для более быстрого формирования результате запроса. Как это работает? Система строит индекс для временной таблицы, чтобы быстрее найти нужное значение.
Т.е. система работает точно так же, как и обычные индексы 1С, только для временной таблицы.
Где и как нужно использовать ИНДЕКСИРОВАТЬ ПО ?
Конструкцию рекомендуется использовать по полям временных таблиц, по которым эта временная таблица будет соединяться с другими таблицами баз данных. Это существенно повышает скорость выполнения соединения таблиц.
Однако следует учесть один момент. Построение индекса временной таблицы также требует времени на выполнение. Поэтому целесообразно использовать конструкцию «ИНДЕКСИРОВАТЬ ПО», только если Вы знаете, что во временной таблице будет не 1-2 записи. В противном случае эффект может быть обратным — быстродействие от индексированных полей не компенсирует времени построения индекса.
Поддержите нас, расскажите друзьям!
СПРОСИТЕ в комментариях!
1. Что значит «рекомендуется использовать по полям временных таблиц, по которым эта временная таблица будет соединяться с другими таблицами баз данных»? У меня есть левое соединение где в правой части — таблица базы данных. Зачем индексировать временную таблицу если при выборке будет проводиться поиск в правой таблице? То есть индекс временной таблицы в данном случае не функционален.
2. Если я связываю 2 временные таблицы левым соединением, какую таблицу я должен индексировать?
3. В приведённом примере — какой смысл индексировать таблицу по единственному полю, если в индексе получается такое же количество записей как в таблице и (следовательно) обход индекса при выборке занимает примерно столько же времени?
Такое впечатление, что писали статью «чтоб было», не думая.
1. Вы просто индексы готовить не умеете, потому как у Вас поверхностные знания общих принципов применения и работы индексов на платформах БД. Вообще есть определенные стандарты, согласно которым проектировщики платформ БД (вменяемые) следуют, иначе спроса на их платформу не будет.
Так вот ответ на ваш вопрос — раз у вас в левом соединении временная таблица и по ней в самом запросе не идут поиск — значит у вас данные из левой таблицы выводятся в результат запроса (иначе зачем тогда Вам вообще левое соединение). А соответственно соединение по имеющимся записям в левой таблице может идти по ее (левой таблицы) индексу или по поиску (перебору) всех записей этой левой таблицы. И так по каждой строке правой. Да, если записей мало — то результат не так заметен, а то и даже… но когда записей много… Поймите — соединение, какое оно бы ни было — это соединение. И в данном случае можно всю таблицу перебирать, а можно по индексу сработать.
2. Если нужно получить максимально быстро результат выборки, особенно если многократно с этими временными таблицами — то обе. При соединении (не важно каком именно) платформа БД при наличии индекса на поле таблице — работает всегда по индексу. Это всегда быстрее.
3. Автор как раз понимает тему, это Вы не в теме и совершенно не представляете как работают индексы. Да, записей в индексе столько же будет, но принцип работы по индексу совершенно другой. Возможно, если у вас обе таблицы абсолютно аналогично отсортированы по полям соединения — то может и не такой эффект будет — но ведь это как правило не так…
В общем вывод — статью писали думая — это Вы ответили, не подумав…
Использование индексов 1С — важнейший момент в оптимизации работы информационной системы 1С. Но они очень часто игнорируются разработчиками.
Ниже я попытаюсь рассказать, что же это такое — индексы 1С 8.3, и как их использовать.
Что же такое индексы в 1С?
Индексы представляют собой структуру, позволяющую выполнять ускоренный доступ к строкам таблицы на основе значений одного или более ее столбцов. Индексы сокращают объем данных, которые необходимо считать, чтобы возвратить результирующий набор.
В 1С индексом таблицы является совокупность реквизитов с установленным флагом «индексировать». Но у каждой таблицы есть свои особенности. Например, в индекс у регистра бухгалтерии автоматически попадают поля период и счет. Их рекомендуют использовать для оптимизации работы системы.
Индекс хранится в отдельной таблице БД, где связывает определенные строки таблицы с ключами индексов. Т.е. при поиске не нужно обходить все строки базы данных, а последовательно по ключам отбирать наборы записей и перебирать уже небольшие наборы информации.
Из-за особенностей СУБД каждая из них накладывает свои ограничения на использования индексов:
Ограничения на индексы в файловой базе 1С
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
В файловой базе единственным ограничением является максимальная длина ключа индекса, которая ограничивается 1920 байтами. При попытке реструктуризации базы данных с ключом большей длины появится ошибка — «Длина ключа индекса превышает максимально допустимую«.
Ограничения на индексы в базе 1С на MS SQL
На MS SQL, согласно документации, к ограничениям по длине индекса добавляется еще и количество ключей индекса, если количество полей будет превышено, индекс просто обрежется:
- количество ключей индекса — максимум 16
- суммарная длина индекса — 900 байт
Рекомендации по оптимизации работы 1С
- не рекомендуется использовать большое количество измерений и субконто в регистрах бухгалтерии;
- в планах счетов в рекомендациях устанавливать не более 4 субконто;
- нежелательно использовать поля составного типа — это сильно понижает скорость работы системы;
- не рекомендуется в измерениях регистров использовать поля с примитивным типом (число, строка и т.п.), если необходимо использовать значения примитивных видов, лучше создайте справочник, где будут указываться данные значения. Например: если Вы используете дату как измерение, лучше создать справочник «Даты», где единственным реквизитом будет реквизит с типом «дата»;
- не индексируйте строковые поля большой длины — это уменьшает быстродействие системы.
Сегодня речь пойдет о индексах СУБД MS SQL и их внутреннем устройстве. Я постараюсь рассказать о индексах и с точки зрения СУБД, и с точки зрения 1С 8.3.
Индексы — набор ссылок, упорядоченных по определенным столбцам, создаваемый с целью оптимизации производительности СУБД MS SQL.
Индексы в 1С
В системе 1С индексы создаются двумя способами — явным и неявным образом.
Создание индексов неявным образом:
Платформа создает индексы сама по заранее известным для каждого объекта метаданных ключам данных (ссылка, код, наименование, измерения и т.п.)
Создание индексов явным образом возможна тремя способами:
- Установка флага «Индексировать» у поля (реквизита/измерения). Вариант «Индексировать с доп. упорядочиванием» добавляет в индекс поле «Код» или «Наименование» (прежде всего для динамических списков).
- Добавление поля в «Критерии отбора«.
- Указание индексируемого поля в запрос с помощью конструкции «ИНДЕКСИРОВАТЬ ПО«.
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Индексы в СУБД Microsoft SQL
Индексы в СУБД MS SQL представляют из себя страницы с данными по 8 Кбайт каждая. Несмотря на то, что индексы призваны улучшить производительность СУБД, у них есть определенные недостатки — они занимают место на диске и замедляют работу СУБД на запись строк.
Виды индексов в СУБД MS SQL:
- Некластерные индексы — такие индексы не перестраивают таблицы, а лишь организуют ссылки.
- Кластерные индексы нужны для построения таблицы в соответствии с индексом. Данные упорядочены, например, по алфавиту. Недопустим для часто изменяющихся столбцов, т.к. СУБД постоянно физически перестраивает таблицу по этому индексу.
- Уникальные индексы — своего рода «надстройка» для кластерных и некластерных индексов. Такой индекс уникален по ключевым полям.
Виды ключей в СУБД:
- Первичный ключ (primary) — набор столбцов, уникально характеризующих строку.
- Внешний ключ (foreign) — поле таблицы, хранящее значение первичного ключа с целью организации связи между таблицами. 1С не использует данный вид ключей.
Важные нюансы использования индексов
Длина ключа индекса в основных СУБД (всех, кроме файлового варианта) — не более 900 байт и 16 различных полей.
Запускайте чаще дефрагментацию индексов на уровне СУБД MS SQL: при частом использовании индексов возможно появление эффекта фрагментации, нельзя допускать уровня фрагментации выше 25%.
Отсутствие индексов может привести к полному сканированию таблицы (table scan), что, в свою очередь, приведет к избыточной блокировке.
Однако не стоит включать индексацию по небольшим наборам данных (например, справочник Организации) — построение индекса может привести к обратному эффекту, быстродействие снизится.
Поддержите нас, расскажите друзьям!
СПРОСИТЕ в комментариях!
«Однако, не стоит включать индексацию по небольшим наборам данных(например, справочник Организации) – построение индекса может привести к обратному эффекту, не уменьшить скорость, а увеличит.».
Видимо ошибка: «… не уменьшить скорость, а увеличит.»
Вы правы. Спасибо большое!
«Внешний ключ (foreign) — 1С не использует данный вид ключей.»
Действительно, эти индексы не используются?
Из литературы вычитал что так, не верно?
Ну почему «Из литературы вычитал»?
Просто странно. По моему, теряются огромные возможности по использованию индексов.
Скорее всего из-за «трудностей перевода» при общении 1С с ms sql.
Согласен, интересно было бы спросить у официальных источников.
И не только с ms sql. У них «хранилищем» могут быть и другие СУБД. Наверное, не надо было изобретать свой язык запросов. Сейчас бы 1С была всеядной в смысле хранилища данных.
Не совсем так. Форэйнкеи в первую очередь нужны для обеспечения целостности данных на уровне СУБД. Так как в 1С используются составные типы данных, т.е в одном поле могут храниться ссылки на праймарикей разных таблиц справочников документов и т.д., то для ФК каждой из этих таблицы пришлось бы использовать отдельное поле, что чревато постоянной реорганизацией таблиц БД.
Недавно столкнулся с такой проблемой: потребовалось обработать большое количество строк (около 1 млн), с последующим left join. Пакетный запрос делал table scan, затем группировал выборку по полям А,Б,С…, выполнял некий отбор. Эти поля и есть поля связи. Сгруппированная выборка связывалась с исходной таблицей, полученной в результате table scan. Рассудив, что неплохо бы проиндексировать эти поля для быстрого поиска, создал индексы в первой и в группированной таблице: индекс(А,Б,С…). Однако, быстродействие вместо того чтобы улучшиться — ухудшилось. Ввиду большого количества строк индексы строился очень долго, занимая примерно 30 процентов времени от общего времени выполнения (судя по плану запроса), а выигрыш в поиске не смог это перекрыть. Без индексов отработало быстрее.
Я что-то сделал не так или можно утверждать, что выигрыш от использования индексов возможен только в случае единичного создания индекса и последующего многократного использования для поиска?
Читайте также: