Covering Index — как реально ускорить SELECT!

Даже с индексом СУБД может работать медленно — после поиска всё равно нужно обращаться к таблице за данными.

Covering Index — это индекс, который уже содержит все данные, нужные запросу.

Если запрос обращается только к колонкам, включённым в индекс — таблица может не читаться вовсе:

CREATE INDEX idx_orders_status_user
ON orders (status, user_id);

Теперь запрос:

SELECT user_id, status
FROM orders
WHERE status = 'pending';

Выполняется полностью из индекса — минимум I/O, максимум скорости.

В PostgreSQL это видно как Index Only Scan в плане:

EXPLAIN ANALYZE SELECT ...

Работает только если строки помечены all-visible (visibility map). В MySQL аналог — Using index, в SQL Server — INCLUDE в индексе.

🔥 Не забывайте: больше индексов = больше места и медленнее вставки/обновления.

➡️ SQL Ready | #совет

🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Москве и поборись за призовой фонд 1 200 000 рублей!

Когда: 25–28 ноября
Формат: онлайн + финал на площадке

Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности
🔹развиваешься в направлении разработки, системной администрации, AI/ML или DevOps
🔹сможешь быть в Москве 28 ноября.

Выбери свой кейс:

✴️VibeCode Jam: собеседование будущего. Создай ИИ-платформу для прохождения технических собеседований с виртуальным интервьюером.

✴️Self-Deploy: CI/CD без DevOps. Автоматизируй генерацию CI/CD пайплайнов по анализу структуры Git-репозитория.

Почему стоит участвовать:
🔘Кейс в портфолио и полезная обратная связь от менторов Т1
🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний
🔘Реальный опыт командной работы
🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.

Регистрация открыта!
➡️ Успей до 23 ноября по ссылке.


Реклама. ООО "ГК "Иннотех" ИНН 9703073496 ERID 2VtzqxXvjVG

💅 InterDB — сайт про внутреннее устройство PostgreSQL!

Если работаешь с базами и хочешь понимать, как Postgres устроен изнутри, этот сайт точно стоит внимания. Здесь подробно объясняется, как хранятся данные, работают индексы, транзакции и репликация. Всё показано на схемах и описано простым языком.

📌 Оставляю ссылочку: interdb.jp

➡️ SQL Ready | #ресурс

RANK vs DENSE_RANK: точное ранжирование в SQL!

При создании рейтингов или аналитических сводок часто нужно определить позиции записей по показателю — с учётом повторов. Для этого используются оконные функции RANK() и DENSE_RANK().

Создадим таблицу с продажами:

CREATE TABLE sales (
  employee TEXT,
  total_sales INT
);

INSERT INTO sales VALUES
('Alice', 500),
('Bob', 700),
('Charlie', 700),
('Diana', 400);

Выполним ранжирование по сумме продаж:

SELECT employee,
       total_sales,
       RANK() OVER (ORDER BY total_sales DESC) AS rank_pos,
       DENSE_RANK() OVER (ORDER BY total_sales DESC) AS dense_rank_pos
FROM sales;

Результат:

employee | total_sales | rank_pos | dense_rank_pos
---------+--------------+----------+----------------
Bob      | 700          | 1        | 1
Charlie  | 700          | 1        | 1
Alice    | 500          | 3        | 2
Diana    | 400          | 4        | 3

🔥 Так что, RANK() пропускает позиции после повторов, а DENSE_RANK() идёт подряд, без «дыр» в нумерации.

➡️ SQL Ready | #практика

Ускоряй отчёты с материализованными представлениями!

Когда отчёты считаются минутами, а данные почти не меняются, решение может быть в кэшировании результата.

Используй материализованное представление (как VIEW, но результат хранится физически в таблице):

CREATE MATERIALIZED VIEW daily_stats AS
SELECT date(created_at) AS day,
       COUNT(*) AS total_orders
FROM orders
GROUP BY 1;

CREATE UNIQUE INDEX ON daily_stats(day);  -- нужно для CONCURRENTLY

Обновлять можно вручную или по расписанию (cron, pg_cron):

REFRESH MATERIALIZED VIEW_stats;

А если нужно без блокировок чтения:

REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats;

🔥 Помни: concurrently медленнее и требует индекс, но позволяет читать данные во время обновления.

➡️ SQL Ready | #совет