Ирина Клёпова

Индексы в SQL: создание, виды и как работают

30 мая 2026

12 минут

Вы пишете простой запрос и ждете быстрый ответ, но база отвечает медленно. Такое часто происходит, когда таблица разрастается и данных становится много. В этот момент обычно вспоминают про индексы. Что такое индекс и почему без него даже обычный поиск превращается в проблему? Многие знают, что они ускоряют работу базы данных. Но как это работает и когда индекс может навредить — понятно не всегда.

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

Что такое индекс в базе данных и зачем он нужен

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

Когда в таблице нет индекса, СУБД вынуждена последовательно просматривать каждую запись — это называется full table scan. При объеме в миллион строк такой подход становится неприемлемо медленным.

Индекс содержит отсортированные копии значений из одного или нескольких столбцов плюс ссылки на физическое размещение строк на диске. Когда вы выполняете WHERE name = 'Иван', база данных сначала обращается к индексу по столбцу name, быстро находит нужные указатели и затем читает только те блоки данных, где действительно лежат нужные записи.

Основные применения индексов:

ускорение выборок данных (SELECT);
быстрая сортировка результатов (ORDER BY);
контроль уникальности значений (UNIQUE);
эффективная стыковка таблиц через JOIN.

Но есть и обратная сторона: любая операция изменения данных (INSERT, UPDATE, DELETE) теперь требует обновления всех затронутых индексов. Поэтому важно не переусердствовать.

Сегодня почти все современные приложения работают с большими объемами данных и понимание индексов в SQL стало базовым навыком даже для junior-разработчиков. Производительность базы часто зависит не от железа, а от того, насколько грамотно написаны запросы и настроены индексы.

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

Как работают индексы в SQL

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

Пример

Есть таблица users с 500 000 строк. Выполним запрос:

EXPLAIN SELECT * FROM users WHERE last_name = 'Петров';

1	EXPLAIN SELECT * FROM users WHERE last_name = 'Петров';

Если индекса на last_name нет, в выводе увидим Seq Scan (последовательное сканирование). Создадим индекс:

CREATE INDEX idx_users_lastname ON users(last_name);

1	CREATE INDEX idx_users_lastname ON users(last_name);

Повторный EXPLAIN покажет Index Scan — база использует структуру индекса. Разница во времени может быть от 2 секунд до 5 миллисекунд.

EXPLAIN ANALYZE добавит реальное время выполнения. Например:

EXPLAIN ANALYZE SELECT * FROM orders WHERE created_at > '2026-01-01';

1	EXPLAIN ANALYZE SELECT * FROM orders WHERE created_at > '2026-01-01';

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

Как работают индексы в SQL на низком уровне? Чаще всего используется B-дерево (B-Tree). Каждый узел дерева содержит диапазоны значений и ссылки на дочерние узлы. Высота дерева даже для миллиарда строк редко превышает 4–5 уровней, что дает логарифмическую сложность поиска O(log n).

Виды индексов в SQL

Существует несколько основных разновидностей, и каждая решает свой класс задач.

Виды индексов по назначению:

B-Tree (дефолтный) — универсальный для =, >, <, >=, <=, BETWEEN, LIKE 'префикс%';

Hash — только для точного равенства (=), не работает с диапазонами. Очень быстр, но не поддерживает сортировку;

GIN (Generalized Inverted Index) — для полнотекстового поиска, массивов, JSONB (PostgreSQL);

GiST — для геоданных (PostGIS), пользовательских типов;

Bitmap — используется некоторыми СУБД для работы с полями с большим количеством повторяющихся значений (например, sex = 'M').

Выбор типа зависит от данных и операций. Для 90% веб-задач достаточно B-Tree.

Не путайте: виды индексов (B-Tree, Hash, GIN) — это про то, как устроен поиск. А типы (кластерный и некластерный) — про то, как индекс связан с таблицей.

Разберем типы подробнее.

Типы индексов SQL

Кластерный индекс определяет физический порядок хранения строк. Таблица может иметь только один кластерный индекс (как книга с одним оглавлением). Если его нет — строки хранятся в виде «кучи» (heap).

Разные СУБД работают по-разному:

в MySQL PRIMARY KEY автоматически создает кластерный индекс;
в SQL Server вы можете явно указать CLUSTERED;
в PostgreSQL кластерный индекс отсутствует в привычном смысле, но есть команда CLUSTER, которая переупорядочивает таблицу по индексу.

Пример создания кластерного индекса:

CREATE CLUSTERED INDEX idx_emp_id ON employees(employee_id);

1	CREATE CLUSTERED INDEX idx_emp_id ON employees(employee_id);

Некластерный индекс — это отдельная структура, которая хранит ключи и указатели на строки. Их может быть много. Когда значение найдено, СУБД делает дополнительное обращение к таблице за полными данными (lookup). Если запрос покрывается всеми нужными столбцами (covering index), extra lookup не нужен.

Индексы в SQL в контексте производительности — инструмент, которым надо управлять осознанно. Например, кластеризовать таблицу по полю, которое часто используется в диапазонах (например, created_at), чтобы связанные данные лежали рядом физически.

При таких сценариях важно не только правильно проектировать индексы, но и контролировать производительность самой СУБД. Нужно отслеживать нагрузку, рост таблиц и эффективность запросов. Для этого можно использовать управляемые PostgreSQL или MySQL-кластеры в Рег.облаке. Это позволит сосредоточиться на работе с данными и оптимизации запросов без ручного администрирования инфраструктуры.

Рассмотрим на примерах, как создавать индексы.

Как создать индекс в SQL

Базовая команда для создания индекса в SQL — CREATE INDEX. Рассмотрим на примерах.

Простой индекс на одном столбце

CREATE INDEX idx_user_email ON users(email);

1	CREATE INDEX idx_user_email ON users(email);

Теперь поиск по email будет быстрым.

Уникальный индекс

Гарантирует, что все значения в столбце различны. Одновременно ускоряет поиск и защищает от дублей.

CREATE UNIQUE INDEX idx_unique_phone ON customers(phone);

1	CREATE UNIQUE INDEX idx_unique_phone ON customers(phone);

Составной индекс (по нескольким столбцам)

Эффективный прием: одним индексом покрываем фильтр по полям (last_name, first_name, birth_date). Но важен порядок: слева должны быть самые селективные поля (с наибольшим разнообразием значений).

CREATE INDEX idx_name_birth ON employees(last_name, first_name, birth_date);

1	CREATE INDEX idx_name_birth ON employees(last_name, first_name, birth_date);

Такой индекс ускорит запросы:

WHERE last_name = 'Иванов'
WHERE last_name = 'Иванов' AND first_name = 'Петр'
WHERE last_name LIKE 'Иван%'

Но не ускорит WHERE first_name = 'Петр', потому что первый столбец last_name не указан.

Индекс с включенными столбцами (PostgreSQL, SQL Server)

Позволяет добавить «нагрузку» без ухудшения поиска. Полезно для покрывающих индексов.

CREATE INDEX idx_orders_date ON orders(order_date) INCLUDE (total_amount, status);

1	CREATE INDEX idx_orders_date ON orders(order_date) INCLUDE (total_amount, status);

Частичный индекс (только для строк, удовлетворяющих условию)

Экономит место и ускоряет запросы к подмножеству данных.

CREATE INDEX idx_active_users ON users(last_login) WHERE is_active = true;

1	CREATE INDEX idx_active_users ON users(last_login) WHERE is_active = true;

Итак, индекс создан. Но не факт, что он работает так, как вы задумали. Иногда разработчики сами себе создают проблемы. Разберем типичные ошибки при использовании индексов, чтобы их избегать.

CREATE INDEX idx_users_email ON users(email); — одна строчка, и запросы ускорились в 100 раз

Ошибки при использовании индексов

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

Индекс на поле с малым количеством значений

Например, sex со значениями 'M' и 'F'. В такой ситуации оптимизатор часто выбирает полное сканирование таблицы, потому что чтение индекса и переход к строкам обходятся дороже.

Функции в WHERE

Запрос

WHERE YEAR(created_at) = 2026

1	WHERE YEAR(created_at) = 2026

не использует индекс по created_at. СУБД сможет использовать индекс, если написать так:

WHERE created_at BETWEEN '2026-01-01' AND '2026-12-31'

1	WHERE created_at BETWEEN '2026-01-01' AND '2026-12-31'

Слишком много индексов

Каждый индекс нужно обновлять при INSERT, UPDATE и DELETE. Если таблица часто меняется, лишние индексы начинают замедлять запись.

Слишком широкий составной индекс

Если добавить в индекс TEXT или длинный VARCHAR, он занимает больше памяти и хуже помещается в кэш. Из-за этого растет нагрузка на диск и падает скорость работы.

Неиспользуемые индексы

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

Самая частая ошибка новичков — создание индексов на всё подряд, не учитывая, что каждый индекс замедляет операции INSERT и UPDATE. Также часто новички не понимают разницу между кластерным и некластерным индексом. И самое критичное — использование индексов без анализа запросов, просто чтобы было. Это все равно что пытаться лечить симптом, не понимая причину проблемы.

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

Когда индексы не нужны или вредны

Иногда отказ от индекса — лучшее решение. Перечислим такие ситуации.

Ситуация	Почему индекс не нужен
Маленькая таблица (менее 1000 строк)	Полное сканирование выполняется быстрее, чем навигация по индексу
Очень редкие запросы к таблице	Индекс будет занимать место и замедлять вставки, но почти никогда не использоваться
Поля с очень высокой частотой изменений	Каждое изменение данных требует обновления индекса — рост I/O и блокировок
Таблица с постоянной записью данных (логи, события)	Лучше не индексировать вообще или использовать минимальное количество (например, только партиционирование)
Условие IS NULL или IS NOT NULL	Поведение NULL зависит от СУБД: современные B-Tree индексы обычно индексируют такие значения, но планировщик может не использовать индекс в некоторых запросах

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

Заключение

Индексы — один из главных инструментов оптимизации SQL-запросов. Они помогают базе быстрее находить данные, но работают эффективно только при правильной настройке. Индекс ускоряет чтение, но при этом замедляет INSERT, UPDATE и DELETE, потому что его нужно постоянно обновлять. Поэтому важно не количество индексов, а то, насколько они соответствуют реальным запросам.

Составной индекс тоже требует внимания: порядок столбцов напрямую влияет на эффективность поиска. Перед созданием индекса стоит проверить запрос через EXPLAIN и понять, действительно ли индекс нужен. Во многих случаях проблема оказывается не в отсутствии индекса, а в самом запросе или структуре таблицы.

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

Индекс в SQL — как кеш в голове. Помните, где лежат ключи? Находите быстро. Не помните? Перебираете весь дом

Частые вопросы

Как проверить наличие индекса в SQL?

В PostgreSQL:

SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'users';

1	SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'users';

В MySQL:

SHOW INDEX FROM users;

1	SHOW INDEX FROM users;

В SQL Server:

SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID('users');

1	SELECT * FROM sys.indexes WHERE object_id = OBJECT_ID('users');

Также можно посмотреть план запроса: если виден Index Scan или Index Seek — индекс используется.

Какие ошибки могут возникнуть при создании индекса?

Частые проблемы: попытка создать индекс с именем, которое уже существует, и слишком длинный ключ. Ошибку можно получить и при создании уникального индекса, если в столбце уже есть дубликаты значений. На больших таблицах создание индекса иногда приводит к блокировке записи. В PostgreSQL для этого используют CONCURRENTLY, чтобы уменьшить влияние на работающую систему.

Как индексы влияют на производительность запросов?

Положительно: ускоряют SELECT, JOIN, ORDER BY в десятки и сотни раз.

Отрицательно: замедляют INSERT, UPDATE, DELETE, потребляют дополнительное дисковое пространство (индекс может быть больше данных). При плохом дизайне (индексы на всё подряд) общая производительность падает из-за постоянного обновления структур. Оптимальный подход — индексы только под критически важные и частые запросы.

Ирина Клёпова

30 мая 2026