Сегодня речь пойдет о индексах СУБД MS SQL и их внутреннем устройстве. Я постараюсь рассказать о индексах и с точки зрения СУБД, и с точки зрения 1С 8.3.

Индексы — набор ссылок, упорядоченных по определенным столбцам, создаваемый с целью оптимизации производительности СУБД MS SQL.

Создание индексов неявным образом:

Платформа создает индексы сама по заранее известным для каждого объекта метаданных ключам данных (ссылка, код, наименование, измерения и т.п.)

Создание индексов явным образом возможна тремя способами:

1. Установка флага «Индексировать» у поля (реквизита/измерения). Вариант «Индексировать с доп. упорядочиванием» добавляет в индекс поле «Код» или «Наименование» (прежде всего для ).
2. Добавление поля в « «.
3. Указание индексируемого поля в запрос с помощью конструкции « «.

Получите 267 видеоуроков по 1С бесплатно:

Индексы в СУБД Microsoft SQL

Индексы в СУБД MS SQL представляют из себя страницы с данными по 8 Кбайт каждая. Несмотря на то, что индексы призваны улучшить производительность СУБД, у них есть определенные недостатки — они занимают место на диске и замедляют работу СУБД на запись строк.

Виды индексов в СУБД MS SQL:

1. Некластерные индексы — такие индексы не перестраивают таблицы, а лишь организуют ссылки.
2. Кластерные индексы нужны для построения таблицы в соответствии с индексом. Данные упорядочены, например, по алфавиту. Недопустим для часто изменяющихся столбцов, т.к. СУБД постоянно физически перестраивает таблицу по этому индексу.
3. Уникальные индексы — своего рода «надстройка» для кластерных и некластерных индексов. Такой индекс уникален по ключевым полям.

Виды ключей в СУБД:

• Первичный ключ (primary) — набор столбцов, уникально характеризующих строку.
• Внешний ключ (foreign) — поле таблицы, хранящее значение первичного ключа с целью организации связи между таблицами. 1С не использует данный вид ключей.

Важные нюансы использования индексов

Грамотное использование индексов может ускорить запросы не просто в разы, а в сотни, иногда даже в тысячи раз.

Такого ускорения просто невозможно добиться аппаратными средствами. Поэтому данной теме необходимо уделить пристальное внимание.

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

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

Настройка индексов штатными средствами платформы

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

Индексация с дополнительным упорядочиванием

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

Создание индекса для измерений регистров

Индексация первого измерения регистров имеет несколько нюансов.
В видео показано, какие индексы создаются для измерений регистров. Также рассмотрена ситуация индексации первого измерения регистра.

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

Кроме варианта "Индексировать" в данном свойстве для большинства объектов можно установить вариант "Индексировать с доп. упорядочиванием". Данный вариант предназначен, прежде всего, для использования в динамических списках.

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

В варианте "Индексировать с доп. упорядочиванием" индекс строится по реквизиту, а также по некоторому полю, которое обычно используется для упорядочивания объектов этого типа. Для справочника индекс в зависимости от основного представления дополняется кодом или наименованием. А для документа, индекс дополняется датой. Этот индекс также дополняется ссылкой.

В варианте "Индексировать" в динамическом списке может быть обеспечен эффективный просмотр больших объемов информации с упорядочиванием по данному реквизиту, так как для этого будет использоваться созданный индекс.

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

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

Таким образом при определении варианта свойства Индексировать следует исходить из того, какие варианты выборки информации необходимо оптимизировать в первую очередь. Например, если требуется просмотр списка с отбором по реквизиту, то имеем смысл использовать вариант "Индексировать с доп. упорядочиванием". А если индекс нужен, например, только для поиска с помощью запроса объектов по данному реквизиту без упорядочивания, то лучше использовать вариант "Индексировать", чтобы создаваемые индекс требовал меньше ресурсов системы.

Подробно состав индексов формируемых системой при различных сочетаниях свойств метаданных приводится в с статье "Индексы таблиц базы данных".

или

Зачем разработчику 1С «индексировать» измерения регистров и реквизиты?

— Ну у вас и запросы! — сказала база данных и повисла…

Краткий ответ на вопрос заголовка заключается в том, что это позволит выполнять запросы быстро и уменьшать негативное влияние блокировок на .

Что такое индекс?

Оптимизация размещения индексов

При объеме таблиц не позволяющем им «разместиться» в оперативной памяти сервера, на первое место выходит скорость дисковой подсистемы (I/O). И здесь можно обратить внимание возможность размещать индексы в отдельных файлах расположенных на разных жестких дисках .

Подробное описание действий http ://technet .microsoft .com /ru -ru /library /ms 175905.aspx
Использование индекса из другой файловой группы повышает производительность некластерных индексов в связи с параллельностью выполнения процессов ввода/вывода и работы с самим индексом.
Для определения размеров можно использовать выше упомянутую обработку.

Влияние индексов на блокировки

Отсутствие необходимого индекса для запроса означает перебор всех записей таблицы, что в свою очередь приводит к избыточным блокировкам, т.е. блокируются лишние записи. Кроме того, чем дольше выполняется запрос из-за отсутствующих индексов, тем больше время удержания блокировок.
Другая причина блокировок — малое количество записей в таблицах. В связи с этим SQL Server, при выборе плана выполнения запроса, не использует индексы, а обходит всю таблицу(Table Scan), блокируя целиком. Для того, чтобы избежать подобных блокировок, необходимо увеличить количество записей в таблицах до 1500-2000. В этом случае сканирование таблицы становится долее дорогостоящей операцией и SQL Server начинает использовать индексы. Конечно это можно сделать не всегда, ряд справочников как «Организации», «Склады», «Подразделения» и т.п. обычно имеют мало записей. В этих случаях индексирование не будет улучшать работу.

Эффективность индексов

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

• Запросы, которые указывают «узкие» критерии поиска. Такие запросы должны считывать лишь небольшое число строк, отвечающих определенным критериям.
• Запросы, которые указывают диапазон значений. Эти запросы также должны считывать небольшое количество строк.
• Поиск, который используется в операциях связывания. Колонки, которые часто используются как ключи связывания, прекрасно подходят для индексов.
• Поиск, при котором данные считываются в определенном порядке. Если результирующий набор данных должен быть отсортирован в порядке кластеризованного индекса, то сортировка не нужна, поскольку результирующий набор данных уже заранее отсортирован. Например, если кластеризованный индекс создан по колонкам lastname (фамилия), firstname (имя), а для приложения требуется сортировка по фамилии и затем по имени, то здесь нет необходимости добавлять инструкцию ORDER BY.

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

Покрывающим (для данного запроса), называется индекс в котором есть все необходимые поля для этого запроса. Например, если индекс создан по колонкам a, b и c, а оператор SELECT запрашивает данные только из этих колонок, то требуется доступ только к индексу.

Для того, что бы определить эффективность индекса, мы можем приблизительно оценить с помощью бесплатного онлайн-сервиса показывающий «план исполнения запроса» и используемые индексы.