Индексы и план запроса в 1С

Индексы из метаданных

Флаг «Индексировать» у реквизита создаёт индекс СУБД по этому полю, и платформа добавляет в него ссылку. Уникальности индекс не даёт: два элемента с одинаковым артикулом запишутся. Вариант «Индексировать с доп. упорядочиванием» добавляет в индекс поле сортировки, и динамический список, который отбирает по реквизиту и сортирует по наименованию, читает порции прямо по индексу.

Индексы создают метаданными, а не руками в СУБД: при реструктуризации платформа пересоздаёт таблицы, и ручной индекс пропадёт. Измерения регистров индексируются платформой сами, порядок измерений задаёт порядок полей индекса.

Составной индекс

Составной индекс работает по первым полям. Индекс по товару и складу помогает отбору по товару, а отбор только по складу пойдёт мимо. Таблица на 200 000 строк, индекс по (товар, склад):

По товару СУБД пошла по индексу (Index Scan): нашла ключ и прочитала одну строку. По складу индекс начинается не с того поля, и СУБД читает таблицу целиком (Seq Scan), проверяя условие на каждой строке. В терминах MS SQL это Seek и Scan.

Для 1С отсюда правило порядка измерений регистра: первыми ставят те, по которым отбирают чаще всего. Регистр с измерениями «склад, товар» плохо отвечает на вопрос «где лежит этот товар».

EXPLAIN (COSTS OFF)
SELECT price FROM prices WHERE item = 777;
EXPLAIN (COSTS OFF)
SELECT price FROM prices WHERE store = 7;

Избирательность и статистика

Индекс полезен, когда условие отбирает малую долю строк. Флаг акции стоит у 1% товаров, по нему есть индекс. Отбор «по акции» и «не по акции»:

Для редкого значения индекс сработал, для частого СУБД читает таблицу целиком: 99% строк всё равно придётся прочитать, и прыжки по индексу только добавят работы. Индекс по полю, где почти все значения одинаковы, ускоряет только поиск редкого значения, а писать в таблицу становится дороже: каждая запись обновляет и индекс.

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

EXPLAIN (COSTS OFF)
SELECT price FROM prices WHERE promo;
EXPLAIN (COSTS OFF)
SELECT price FROM prices WHERE NOT promo;

Как отвечать: «Добавили флаг Индексировать на реквизит, а запрос не ускорился. Почему?»

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

Ответ перебирает причины от кода к СУБД и заканчивается проверкой по плану. Это показывает, что кандидат не верит флагу на слово.

На чём валят

• −Ждут уникальности от флага Индексировать. Индекс не уникальный. Уникальность проверяют кодом или запросом.
• −Индексируют булево поле, где 99% значений одинаковы. По частому значению индекс не помогает, а запись дорожает.
• −Отбирают по второму полю составного индекса. Индекс читается целиком или не используется. Порядок полей под частые отборы.
• −Не обновляют статистику после массовой загрузки. Планы деградируют. Статистику обновляют регламентом.