← На главную

При оптимизации запросов к базе данных PostgreSQL в среде 1С разработчики часто сталкиваются с вопросом интерпретации планов выполнения запросов. Одной из распространенных «загадок» является ситуация, когда при наличии подходящего индекса (например, по полям Родитель и ЭтоГруппа) планировщик выбирает метод Index Scan вместо ожидаемого Index Seek. Давайте разберемся, почему это происходит и всегда ли это является признаком неэффективности.

Понимаем разницу между методами сканирования

Для начала важно прояснить терминологию. Хотя в профессиональной среде часто используются термины Index Seek и Index Scan, в PostgreSQL документации мы чаще встречаем понятия Index Scan и Index Only Scan.

1. Index Scan: База данных обращается к индексу, находит записи, соответствующие критериям поиска, и затем «ходит» в основную таблицу (Heap) за данными, которых нет в индексе. Это стандартная операция, когда индекс помогает найти нужные строки, но не содержит всех запрашиваемых полей.
2. Index Only Scan: Идеальный сценарий, при котором вся необходимая для результата запроса информация уже содержится в индексе. В этом случае обращение к таблице не требуется, что значительно экономит ресурсы.

Таким образом, использование Index Scan — это не ошибка, а штатный процесс извлечения данных, когда индекс используется как «указатель» на нужные записи в таблице.

Почему планировщик выбирает именно этот путь?

Разберем основные причины, по которым PostgreSQL может предпочесть Index Scan:

• Малый объем данных: Если справочник содержит всего несколько сотен записей (как в нашем примере с 40 группами и 500 элементами), планировщик может решить, что затраты на «прыжки» между страницами индекса и таблицы выше, чем простое последовательное чтение всей таблицы (Sequential Scan).
• Полнота условий в запросе: Правило «левого префикса» гласит, что индекс эффективно работает, если в условии WHERE указано первое поле индекса. Если вы фильтруете только по последующим полям (например, по ПометкеНаУдаление без указания Родителя), индекс теряет свою эффективность, так как B-дерево не может однозначно определить область поиска. В таких случаях Index Scan по всей структуре индекса неизбежен.
• Состав запрашиваемых полей: Если вы выбираете реквизиты, не входящие в состав индекса, планировщик вынужден использовать индекс для навигации, а затем подтягивать недостающие данные из основной таблицы.

Анализируем влияние дополнительных условий

Часто возникает вопрос: «Почему индекс срабатывает, даже если я добавил дополнительные условия, которых нет в структуре индекса?». Важно помнить, что наличие условия в WHERE не отменяет индекс, а служит фильтром.

Рассмотрим, как это происходит на практике:

Допустим, у нас есть индекс по полям: Родитель + ЭтоГруппа. Если мы добавляем в запрос ПометкаНаУдаление, планировщик выполняет следующие шаги:

1. Использует индекс для поиска диапазона, соответствующего Родителю и ЭтоГруппе.
2. Отфильтровывает найденные записи по полю ПометкаНаУдаление.

В этом случае индекс «работает» в качестве инструмента первичного отсечения данных. Это значительно эффективнее, чем просмотр всей таблицы, даже если в плане выполнения отображается Index Scan.

Как добиться максимальной производительности

Если вы хотите перевести выполнение запроса в более быстрый режим, обратите внимание на следующие методы оптимизации:

1. Покрывающие индексы: Если запрос критически важен и выполняется часто, рассмотрите возможность включения часто запрашиваемых полей в состав индекса. В PostgreSQL это можно сделать, создав индекс, который включает (INCLUDE) дополнительные поля. Это позволит планировщику выполнить Index Only Scan.
2. Анализ статистики: Убедитесь, что статистика по таблице актуальна (выполнена команда ANALYZE). Планировщик принимает решения на основе оценки количества строк, и устаревшие данные могут приводить к выбору неоптимальных планов.
3. Анализ структуры запроса: Старайтесь, чтобы в условиях соединения и фильтрации первыми всегда шли поля, являющиеся ведущими частями ваших индексов.

Заключение

В работе с 1С и PostgreSQL не стоит пугаться Index Scan. Это естественная работа оптимизатора. Важно анализировать, насколько сужается выборка при использовании индекса. Если индекс отсекает 99% данных, он работает отлично, даже если база данных совершает дополнительные обращения к таблице. Оптимизируйте запросы, исходя из реальной стоимости операций, а не только из названий методов сканирования в плане выполнения.