SQL Ready | Базы Данных

Почему коррелированные подзапросы могут снижать производительность SQL-запроса! Коррелированные подзапросы удобны: внутри них можно обращаться к значениям текущей строки внешнего запроса. Проблема в том, что оптимизатор может выбрать план, при котором такой подзапрос будет выполняться повторно для каждой строки внешней выборки. На больших объёмах данных это может стать узким местом. Например:

SELECT
    u.id,
    u.name,
    (
        SELECT SUM(o.amount)
        FROM orders o
        WHERE o.user_id = u.id
    ) AS total_amount
FROM users u;

Если users содержит миллион строк, подзапрос потенциально может быть выполнен миллион раз. Даже при наличии индекса по orders.user_id такой подход иногда становится менее эффективным, особенно в сложных отчётах. Часто можно сначала агрегировать данные, а затем присоединить результат:

SELECT
    u.id,
    u.name,
    COALESCE(o.total_amount, 0) AS total_amount
FROM users u
LEFT JOIN (
    SELECT
        user_id,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY user_id
) o
ON o.user_id = u.id;

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

SELECT
    user_id,
    created_at
FROM (
    SELECT
        user_id,
        created_at,
        ROW_NUMBER() OVER (
            PARTITION BY user_id
            ORDER BY created_at DESC
        ) AS rn
    FROM orders
) t
WHERE rn = 1;

Но и здесь нет универсального решения. При правильном индексе, например:

(user_id, created_at DESC)

коррелированный запрос вида:

SELECT ...
FROM orders
WHERE user_id = ?
ORDER BY created_at DESC
LIMIT 1;

может быть быстрее, потому что база сможет быстро найти одну нужную строку через индекс. Делаем вывод: коррелированные подзапросы сами по себе не являются ошибкой. Они могут быть как хорошим решением, так и причиной проблем с производительностью — всё зависит от данных, индексов и выбранного плана выполнения. 🔥 В больших отчётах и высоконагруженных API всегда проверяйте фактический план выполнения. Иногда JOIN, предварительная агрегация или оконные функции позволяют значительно уменьшить количество лишних операций. ➡️ SQL Ready | #практика

Уже очевидно, что ВАЙБКОДИНГ — главный навык ближайших лет Посмотрите сами. ИИ уже забирает на себя работу целых команд: пишет код, закрывает задачи джунов и позволяет стартапам запускать продукты в 2–3 раза меньшим составом. То, на что раньше нужны были несколько разработчиков, сегодня всё чаще делает один человек с ИИ-агентами. И это только начало. Те, кто освоит вайбкодинг сейчас, смогут быстрее запускать проекты, автоматизировать огромный объём работы, увереннее конкурировать на рынке и зарабатывать больше тех, кто продолжает делать всё вручную. Начать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы. Подписывайтесь, нас уже 60 тысяч: @vibecoding_tg

📂 Шпаргалка по Backend-разработке! Например, REST используется для построения API, Redis помогает кэшировать данные, а Docker позволяет упаковать приложение вместе со всеми его зависимостями. На картинке — основные направления Backend-разработки: языки программирования, базы данных, API, авторизация, серверы, контейнеризация, CI/CD и мониторинг. Полезная карта того, что стоит изучить Backend-разработчику. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Научите оптимизатор понимать ваши данные! PostgreSQL по умолчанию считает, что значения в разных колонках независимы друг от друга. Но в реальных данных это часто не так. Например, если city = 'Paris', то country почти всегда будет 'France'. Без этой информации оптимизатор может сильно ошибиться при оценке количества строк и выбрать неудачный план.

EXPLAIN
SELECT *
FROM users
WHERE country = 'France'
  AND city = 'Paris';

Вместо того чтобы сразу создавать новый индекс, попробуйте расширенную статистику.

CREATE STATISTICS users_dep (dependencies)
ON country, city
FROM users;

ANALYZE users;

После ANALYZE PostgreSQL сможет учитывать зависимость между колонками и точнее оценивать селективность условий. Во многих случаях этого достаточно, чтобы оптимизатор выбрал более эффективный план выполнения. 🔥 Если запрос фильтрует по нескольким связанным колонкам и оптимизатор ошибается в оценке, сначала попробуйте CREATE STATISTICS, а уже потом решайте, нужен ли новый индекс. ➡️ SQL Ready | #совет

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку Окружение решает больше, чем кажется. Собрал папки и каналы, где можно быстрее влиться в нужное направление, следить за трендами и не вариться в своём пузыре. AI: t.me/ai_machinelearning_big_data Python: t.me/pythonl Linux: t.me/linuxacademiya Хакинг: t.me/linuxkalii ВАЙБКОДИНГ: t.me/data_analysis_ml DevOps: t.me/DevOPSitsec Docker: https://t.me/+90Z5TAyfuNU5YmRi Golang: t.me/Golang_google Rust: t.me/rust_code C++: t.me/cpluspluc C#: t.me/csharp_1001_notes Java: t.me/javatg JavaScript: t.me/javascriptv React: t.me/react_tg PHP: t.me/phpshka Android: t.me/android_its Мобильная разработка: t.me/mobdevelop Базы данных: t.me/sqlhub Big Data: t.me/bigdatai Математика: t.me/data_math Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка Frontend: https://t.me/addlist/mzMMG3RPZhY2M2Iy ИТ-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy Max Ai: https://max.ru/ai_machinelearning_big_data Max python: https://max.ru/pythonl ТЕХНО: https://max.ru/vistehno Max Go: https://max.ru/Golang_google Max Linux: https://max.ru/linuxkalii Devops: https://max.ru/DevOPSitsec C#: https://max.ru/csharp_ci C++: https://max.ru/cpluspluc SQL: https://max.ru/sqlhub Java: https://max.ru/javatg Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд.

🤔 SQL Lab — интерактивная платформа для изучения и практики SQL! Сайт для тех, кто хочет освоить SQL через работу с запросами. Код пишется прямо в браузере: выполняете запрос, сразу видите результат и получаете автоматическую проверку решения. Обучение построено от базовых SELECT и ORDER BY до JOIN, подзапросов, транзакций, индексов, оптимизации запросов и PostgreSQL. Есть структурированные курсы с теорией и практикой. 📌 Оставляю ссылочку: sqllab.ru ➡️ SQL Ready | #ресурс

UNIQUE и NULL в PostgreSQL 15! До PostgreSQL 15 уникальные ограничения считали NULL разными значениями. Это означало, что таблица спокойно принимала сколько угодно строк с NULL, даже если на колонке стоял UNIQUE.

CREATE TABLE users (
    email text UNIQUE
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Обе вставки выполнятся успешно. Если NULL тоже должен быть уникальным, приходилось придумывать обходные пути. Кто-то делал частичные индексы, кто-то использовал COALESCE(), кто-то заводил отдельные флаги.

CREATE TABLE users (
    email text,
    CONSTRAINT users_email_key
        UNIQUE NULLS NOT DISTINCT (email)
);

INSERT INTO users VALUES (NULL);
INSERT INTO users VALUES (NULL);

Вторая вставка уже завершится ошибкой. Для ограничения NULL считается таким же значением, как и любой другой ключ.

CREATE TABLE users (
    tenant_id int,
    email text,
    CONSTRAINT uq_user
        UNIQUE NULLS NOT DISTINCT (tenant_id, email)
);

Полезно, когда NULL — это полноценное значение предметной области, а не просто "неизвестно". 🔥 Небольшая возможность PostgreSQL 15, которая позволяет удалить сразу несколько старых костылей вокруг UNIQUE. ➡️ SQL Ready | #совет

+85.000р. получил в январе +141.000р. пришло в июне +187.000р. получил в июле Согласись, похоже на цифры с потолка. Но так сейчас зарабатывает Андрей Д. на запуске контент-заводов для бизнеса. В 2026 бизнес по всей РФ начал активно внедрять ИИ, чтобы автоматизировать создание текстов, видео и фото для соцсетей и маркетплейсов. Такие ИИ настраивает Евгений Андрианов с командой. Андрей присоединился к команде Евгения и за пару недель с нуля научился работать с ИИ. На старте он заработал 85 тыс., а сейчас вышел на более 180 тыс в месяц. Как это работает: - Проходишь обучение пару недель; - Получаешь реальный заказ из базы; - Собираешь ИИ-контент-завод по формуле; - Сдаёшь проект — получаешь деньги. Объём работом выбираешь сам. График свободный. Средний доход участников команды — 92 852р. в месяц. Не нужно искать клиентов самостоятельно. Не нужен опыт. Не требуется техническое образование. Всё, что нужно для старта — запустить вводный инструктаж на сайте бесплатно. Осталось 14 мест. 👉 Пробуй Реклама. ООО "АИМ" ИНН 9723249701

❤️ Интересная статья на Хабре: «Что такое RAGFlow и с чем его едят»! В этой статье: • Разберётесь, как RAGFlow помогает LLM работать с внутренними документами и снижать количество галлюцинаций; • Узнаете, чем RAGFlow отличается от классического RAG и как он обрабатывает PDF, таблицы, схемы и сканы; • Посмотрите, как развернуть RAGFlow и использовать его для баз знаний, техподдержки и аналитики.

🔊 Продолжай читать на Habr!

➡️ SQL Ready | #статья

📂 Шпаргалка по нормализации баз данных в MySQL! Например, 1NF требует атомарных значений, 2NF избавляет от частичных зависимостей, а 3NF — от транзитивных. Для более сложных схем пригодятся BCNF и 4NF. На картинке — основные нормальные формы с требованиями, примерами и пользой каждой из них. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

🖥 PostgreSQL — блокировки строк и конкурентный доступ! Шпаргалка по механизмам синхронизации параллельных транзакций в PostgreSQL: защита строк от конкурентных изменений и удаления, управление ожиданием и пропуском занятых строк, явная блокировка таблиц и диагностика ожидающих блокировок. Помогает контролировать конкурентный доступ и корректно реализовывать транзакционные сценарии. ➡️ SQL Ready | #шпора

👨‍💻 Junior Database — база вопросов и ответов по SQL и базам данных! В репозитории собраны 27 тем, которые часто встречаются при изучении баз данных и подготовке к техническим собеседованиям: транзакции и ACID, нормализация и денормализация, первичные и внешние ключи, JOIN, GROUP BY и HAVING, индексы, миграции, хранимые процедуры и триггеры. Также затрагиваются оптимизация запросов, партицирование, репликация, шардинг и различия между SQL и NoSQL. Оставляю ссылочку: GitHub 📱 ➡️ SQL Ready | #репозиторий

📂 SQL в одной шпаргалке! Например, SELECT, WHERE и ORDER BY отвечают за выборку, фильтрацию и сортировку данных, JOIN связывает таблицы, а GROUP BY, агрегатные и оконные функции помогают анализировать результаты запросов. На картинке — структурированная карта SQL: от базовых запросов и объединения таблиц до CTE, подзапросов, DDL/DML/DCL/TCL, транзакций и ограничений целостности данных. Сохрани, чтобы не потерять! ➡️ SQL Ready | #ресурс

Работайте с периодами как с одним значением! Когда у записи есть start_at и end_at, проверки пересечений быстро превращаются в набор сравнений. В PostgreSQL для этого есть range types: например, tstzrange для диапазона timestamptz. Вместо:

WHERE start_at < :end_at
  AND end_at > :start_at

можно явно работать с диапазонами:

WHERE tstzrange(start_at, end_at, '[)')
   && tstzrange(:start_at, :end_at, '[)')

Оператор && означает «диапазоны пересекаются». [) задаёт полуинтервал: начало включено, конец исключён, поэтому встреча до 12:00 и следующая с 12:00 не считаются пересекающимися. Но интереснее то, что PostgreSQL умеет проверять диапазоны и другими операторами:

period @> now()       -- содержит момент времени
period && :period     -- пересекается
period <@ :period     -- находится внутри

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

CREATE INDEX bookings_period_idx
ON bookings USING gist (period);

И самое полезное: правило «для одной комнаты интервалы не должны пересекаться» можно перенести из приложения непосредственно в БД:

CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE bookings
ADD CONSTRAINT bookings_no_overlap
EXCLUDE USING gist (
    room_id WITH =,
    period  WITH &&
);

Теперь две пересекающиеся брони одной комнаты физически нельзя записать, даже если два конкурентных запроса одновременно прошли предварительную проверку в приложении. 🔥 Range types превращают интервалы времени из пары колонок и ручной логики в полноценный тип данных: его можно сравнивать, индексировать и даже запретить пересечения на уровне констрейнта. ➡️ SQL Ready | #совет

Очнись, нас готовят к цифровому ГУЛАГу Уже в десятках регионов России отключают мобильный интернет (даже когда нет атак БПЛА), тестируют «белые списки» и замедляют Телегу. 90% людей тупо смотрят на уплывающий корабль свободного Интернета. Люди поумнее готовятся к новой реальности и читают «Пакет Безопасности». Здесь дают самые свежие связки для приватности: приложения и утилиты на случай вайтлистов, прокси, браузеры, сервисы — чего тут только нет. Без шуток, сейчас это один из самых полезных каналов в Телеге. Надеемся на лучшее, но к чему нужно готовиться — вы и сами понимаете: @package_security

👨‍💻 Koddo — сайт с теорией и практикой для обучения! Платформа для изучения SQL через решение реальных задач прямо в браузере. На практике разбираются выборки и фильтрация, GROUP BY и HAVING, JOIN, работа с датами, подзапросы, CTE и оконные функции. Решения автоматически проверяются, а AI-ассистент может дать подсказку, не раскрывая готовый ответ. 📌 Оставляю ссылочку: koddo.ru ➡️ SQL Ready | #ресурс

🖥 Oracle — преобразование и проверка данных! Шпаргалка по преобразованию и проверке данных в Oracle: работа со строками, числами, датами, временем и Unicode. Используется для явного преобразования типов, форматирования значений, проверки корректности входных данных и обработки символьных данных. ➡️ SQL Ready | #шпора

Временные таблицы: различия между TEMP, CTE и материализацией данных! В SQL существует несколько способов работать с промежуточными результатами. Основные варианты — временные таблицы, CTE через WITH и обычные подзапросы. Выбор между ними влияет на читаемость запроса, возможность повторного использования данных и работу оптимизатора. Временная таблица создаётся внутри текущей сессии базы данных и существует до её завершения или до явного удаления. Она подходит для многоэтапной обработки данных, когда результат нужно использовать в нескольких следующих запросах.

CREATE TEMP TABLE monthly_sales AS
SELECT
    customer_id,
    SUM(amount) AS total_amount
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY customer_id;

После создания временная таблица становится отдельным объектом базы данных. К ней можно обращаться как к обычной таблице, создавать индексы и выполнять дополнительные операции.

SELECT *
FROM monthly_sales
WHERE total_amount > 10000;

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

CREATE INDEX idx_monthly_sales_customer_id
ON monthly_sales(customer_id);

CTE (Common Table Expression) создаётся с помощью конструкции WITH и существует только во время выполнения одного SQL-запроса. Он помогает сделать сложную логику более читаемой и структурированной.

WITH monthly_sales AS (
    SELECT
        customer_id,
        SUM(amount) AS total_amount
    FROM orders
    GROUP BY customer_id
)
SELECT *
FROM monthly_sales
WHERE total_amount > 10000;

В PostgreSQL начиная с версии 12 CTE может быть автоматически встроен оптимизатором в основной запрос. Это называется CTE inlining. В таком случае отдельное промежуточное хранилище данных не создаётся.

WITH active_users AS MATERIALIZED (
    SELECT *
    FROM users
    WHERE status = 'active'
)
SELECT *
FROM active_users;

Основное отличие MATERIALIZED заключается в том, что PostgreSQL принудительно сохраняет результат CTE перед дальнейшей обработкой. Это может быть полезно, если один и тот же результат используется несколько раз или нужно избежать повторного выполнения тяжёлого вычисления.

WITH user_stats AS MATERIALIZED (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
)
SELECT
    a.user_id,
    a.orders_count
FROM user_stats a
JOIN user_stats b
    ON a.user_id = b.user_id;

Однако использование CTE не всегда означает материализацию. PostgreSQL самостоятельно выбирает оптимальный способ выполнения запроса, если не указано MATERIALIZED или NOT MATERIALIZED.

WITH user_stats AS NOT MATERIALIZED (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
)
SELECT *
FROM user_stats;

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

CREATE TEMP TABLE user_stats AS
SELECT
    user_id,
    COUNT(*) AS orders_count
FROM orders
GROUP BY user_id;

CREATE INDEX idx_user_stats_user_id
ON user_stats(user_id);

ANALYZE user_stats;

Команда ANALYZE после заполнения временной таблицы помогает PostgreSQL получить актуальную статистику и выбрать более эффективный план выполнения запроса. Обычный подзапрос существует только внутри конкретного SQL-выражения. Он подходит для локальных вычислений, когда результат нужен только в одном месте и не требуется повторное использование.

SELECT *
FROM (
    SELECT
        user_id,
        COUNT(*) AS orders_count
    FROM orders
    GROUP BY user_id
) s
WHERE orders_count > 50;

🔥 Выбор подходящего варианта зависит от задачи. CTE обычно используют для повышения читаемости и разделения сложной логики внутри одного запроса. Временные таблицы подходят для многошаговой обработки, больших промежуточных результатов и случаев, когда нужны индексы. Подзапросы удобны для простых локальных вычислений внутри одного SQL-выражения. ➡️ SQL Ready | #практика

Оффер в IT за 3 дня - да! Вот такой крутой кейс получился у команды ИИ-ассистента Софи🤘 Пользователь зашел на триал, не заплатил за подписку и успел получить оффер с отклика, который сделал бот. ▫️Направление - бэкенд разработка ▫️3 приглашения на собес за 72 часа ▫️Оффер, с зарплатой на 20.000 больше указанной в резюме Если тоже хочешь попробовать 3 бесплатных дня в Софи - доступ открыт, регистрируйся здесь.