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

Мы протестировали каждый приведенный ниже метод на одном миллионе сгенерированных строк в SQLite 3.50. Тайминги — лучшие из нескольких запусков с одного ноутбука с использованием базы данных в памяти. Они не подойдут вашей системе, а PostgreSQL, MySQL и SQL Server имеют свои собственные оптимизаторы и форматы планов. Сосредоточьтесь на размере каждого улучшения и на принципах, лежащих в его основе.

Результаты с первого взгляда

Тестовая установка

CREATE TABLE customers (
  id INTEGER PRIMARY KEY, name TEXT, city TEXT
);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY, customer_id INT, status TEXT,
  created TEXT, total INT, note TEXT
);
-- 50,000 customers and 1,000,000 orders with random values

Простой процесс оптимизации

1. Найдите важные запросы. Используйте журналы медленных запросов или мониторинг. Запрос длительностью 200 мс, выполняемый тысячу раз в минуту, может иметь большее значение, чем 10-секундный ежемесячный отчет.
2. Прочитайте план. Посмотрите, что на самом деле делает база данных.
3. Измените одну вещь. Добавьте индекс или перепишите часть запроса.
4. Измерьте еще раз на реалистичных данных. План на 100 тестовых строк мало что скажет о миллионе.
5. Следите за развитием событий. Планы могут меняться по мере роста данных и изменения статистики.

Прочитать план выполнения

План выполнения — это пошаговая стратегия базы данных для выполнения запроса, в том числе, какие индексы она использует и в каком порядке она объединяет таблицы. Префикс запроса, чтобы увидеть его:

Обратите внимание, что EXPLAIN ANALYZE в PostgreSQL действительно запускает запрос, поэтому будьте осторожны при использовании его с UPDATE или DELETE. Вот что нужно искать в первую очередь:

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

Добавьте правильный индекс

Этот запрос находит заказы одного клиента:

SELECT id, total FROM orders WHERE customer_id = 123;

Перед добавлением индекса планировалось полное сканирование:

SCAN orders
-- 20 rows in 73 ms

Затем мы добавили индекс в столбец фильтра:

CREATE INDEX idx_orders_customer ON orders(customer_id);

SEARCH orders USING INDEX idx_orders_customer (customer_id=?)
-- 20 rows in 0.01 ms

Те же 20 строк возвращались в тысячи раз быстрее, потому что база данных больше не читала миллион строк, чтобы найти их. Никакая другая техника в этой статье не дала нам большего выигрыша. Хорошими первыми кандидатами являются столбцы, используемые в WHERE, JOIN и ORDER BY, особенно когда они сужают результаты до нескольких строк. Наше руководство по индексам SQL объясняет, как они работают.

Не переносите индексированные столбцы в функции

Вот два способа найти мартовские заказы с индексом created:

-- Function on the column
SELECT id FROM orders WHERE substr(created, 1, 7) = '2026-03';
-- SCAN orders USING COVERING INDEX idx_orders_created
-- 84,961 rows in 96 ms

-- Plain range
SELECT id FROM orders
WHERE created >= '2026-03-01' AND created < '2026-04-01';
-- SEARCH orders USING COVERING INDEX idx_orders_created (created>? AND created<?)
-- 84,961 rows in 33 ms

Оба возвращают одинаковые строки, но первый занял примерно в три раза больше времени. План показывает, почему: при наличии функции в столбце база данных не может перейти к позиции в отсортированном индексе, поэтому ей приходится проходить SCAN через каждую запись. Версия диапазона может SEARCH прямо в нужное место. Условие, которое может использовать индекс таким образом, называется sargable.

Та же проблема возникает со следующими распространенными шаблонами:

Последнее мы тоже проверили. Создается ведущий подстановочный знак SCAN customers, поскольку индекс, отсортированный по первой букве, не может помочь с совпадением в конце.

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

Когда запрос фильтруется по двум столбцам, индекс по одному столбцу выполняет лишь часть работы:

SELECT id FROM orders
WHERE status = 'paid'
  AND created >= '2026-03-01' AND created < '2026-03-08';

-- Using only the created index: 6,198 rows in 19 ms

CREATE INDEX idx_status_created ON orders(status, created);

-- SEARCH orders USING COVERING INDEX idx_status_created
--   (status=? AND created>? AND created<?)
-- 6,198 rows in 2.2 ms

Порядок столбцов имеет большое значение. Индекс на (status, created) работает как телефонная книга, отсортированная по фамилии, а затем по имени. Вы можете найти только фамилию, но не только имя. Наш запрос только к status мог бы использовать этот индекс. Фильтрация только по created обычно не может эффективно использовать его. Как правило, сначала помещайте столбцы, проверенные на равенство, а затем — столбцы диапазона.

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

Более быстрая нумерация страниц

Использование OFFSET для глубоких страниц — это скрытые затраты, поскольку базе данных все равно приходится проходить мимо всех пропущенных строк:

-- Page deep into the results
SELECT id FROM orders ORDER BY id LIMIT 20 OFFSET 500000;
-- 8.1 ms

-- Keyset pagination: continue from the last id seen
SELECT id FROM orders WHERE id > 500000 ORDER BY id LIMIT 20;
-- 0.01 ms

Пагинация набора ключей остается быстрой независимо от того, насколько глубоко вы погружаетесь. Это также позволяет избежать смещения строк между страницами при добавлении новых данных. Компромисс заключается в том, что пользователи не могут сразу перейти к 5000-й странице, что редко является реальной необходимостью. В таблицах с широкими строками или с большим количеством строк, которые нужно пропустить, разрыв может быть намного больше, чем в нашем тесте.

Пишите более компактные запросы

• Выбирайте только те столбцы, которые вам нужны. SELECT * отправляет больше данных и может помешать индексу покрыть запрос.
• Ранняя фильтрация. Используйте WHERE для удаления строк перед группировкой и HAVING только для условий агрегатов. См. SQL GROUP BY и HAVING.
• Используйте LIMIT, если вам нужно всего несколько строк.
• Предпочитайте UNION ALL, если вам не нужно удалять дубликаты. Наш тест UNION vs UNION ALL показывает, какую экономию это дает.
• Избегайте ненужных DISTINCT. Часто скрывается соединение, создающее дубликаты.
• Используйте EXISTS для проверки существования. Она может остановиться при первом совпадении, как объясняется в нашем руководстве по подзапросам SQL.
• Следите за N+1 запросами. Реальной проблемой часто является один запрос на строку в цикле, обычно вызванный кодом приложения. Одно соединение или пакетный запрос могут заменить сотни обращений туда и обратно.

Присоединяется

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

SELECT c.name, SUM(o.total)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.city = 'Goa'
GROUP BY c.id;

-- SCAN c
-- SEARCH o USING COVERING INDEX idx_cover (customer_id=?)
-- 9,900 rows in 34 ms

Он сканирует клиентов, а затем использует индекс для поиска заказов каждого из них. Без индекса по orders.customer_id базе данных пришлось бы выполнять гораздо больше работы для каждого клиента. Индекс внешнего ключа — одно из наиболее распространенных и ценных дополнений, которые вы можете сделать. Чтобы освежить ваше понимание основ, см. Объяснение объединений SQL.

Когда индексы обходятся вам дорого

Индексы не бесплатны, поэтому не добавляйте их для каждого столбца:

• Запись медленнее. Каждая вставка, обновление и удаление также должны обновлять каждый индекс.
• Больше места для хранения и памяти. Индексы могут увеличиваться в размерах в больших таблицах.
• Небольшая польза от неселективных столбцов. Индекс для истинного или ложного столбца может не помочь, если большинство строк совпадают.
• Избыточность. Индекс в (a) часто не нужен, если он у вас уже есть в (a, b).

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

Распространенные ошибки

• Оптимизация без измерений. Многие уверенные предположения оказываются ошибочными.
• Тестирование на небольших объемах данных. Планы и сроки резко меняются по мере роста таблиц.
• Доверяем совету для другой базы данных. Советы для одного движка могут быть неприменимы к другому.
• Добавление индексов вслепую. Каждый из них тормозит запись.
• Игнорирование эффекта первого запуска. Кэши ускоряют второй запуск, поэтому запускайте его несколько раз.

Итоги

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

Часто задаваемые вопросы

Продолжайте учиться