Покрывающий индекс — это [[Индекс базы данных|индекс]], который включает в себя все колонки, необходимые для выполнения определенного запроса, без необходимости обращения к основной таблице данных.
Обычный индекс позволяет ускорить поиск по ключевой колонке, но при этом, чтобы получить данные из других колонок, СУБД все равно обращается к основной таблице. ==Покрывающий индекс, в отличие от обычного, содержит все необходимые для запроса колонки, что исключает необходимость обращения к таблице и, следовательно, улучшает производительность.==
Однако это не всегда так: иногда СУБД всё же вынуждена обратиться к таблице, поскольку индекс не хранит информацию о**видимости строк** — данных, которые управляют их доступностью в текущей транзакции. В системах с многоверсионной архитектурой (например, в PostgreSQL) строки могут быть изменены, удалены или добавлены другими транзакциями, которые ещё не завершены. Это создаёт «несогласованные» версии данных, и СУБД нужно проверить, какая версия строки видима в текущем запросе.
Пример создания покрывающего индекса в [[../../meta/zero/00 PostgreSQL|PostgreSQL]]:
```sql
CREATE INDEX idx_example ON table_name (column1) INCLUDE (column2);
```
Такой индекс включает колонку `column1` для индексирования и добавляет `column2`, которая не индексируется, но хранится рядом с индексом. Это позволяет выполнять следующий запрос, не обращаясь к основной таблице:
```sql
SELECT column1, column2 FROM table_name WHERE column1 = 'value';
```
**Преимущества**:
- Значительное улучшение производительности запросов, так как нет необходимости обращаться к основной таблице.
- Уменьшение числа обращений к диску, особенно для часто используемых запросов с выборкой нескольких колонок.
**Недостатки**:
- Покрывающие индексы могут занимать больше места в памяти, особенно если в них включены несколько дополнительных колонок.
- Увеличение времени на операции вставки, обновления и удаления, так как индекс требует обновления при изменениях данных.
**Покрывающие индексы стоит использовать в следующих случаях:**
- Для оптимизации часто выполняемых SELECT-запросов, которые выбирают несколько колонок.
- Когда необходимо минимизировать количество обращений к диску, чтобы ускорить выполнение запросов.
- Для [[Online Analytical Processing|OLAP]], где важно быстрое чтение данных без необходимости частых обновлений.