SQL-совет 💡
Если в запросе используется
❌ Часто медленно:
✅ Обычно быстрее и безопаснее:
Почему это важно:
-
-
- Лучше масштабируется на больших данных
- Меньше сюрпризов с NULL
Особенно критично в PostgreSQL, MySQL и Oracle на больших таблицах.
Если в запросе используется
IN (subquery) - почти всегда выгоднее заменить его на EXISTS.❌ Часто медленно:
SELECT *
FROM orders o
WHERE o.user_id IN (
SELECT u.id FROM users u WHERE u.country = 'US'
);
✅ Обычно быстрее и безопаснее:
SELECT *
FROM orders o
WHERE EXISTS (
SELECT 1
FROM users u
WHERE u.id = o.user_id
AND u.country = 'US'
);
Почему это важно:
-
IN может материализовать подзапрос целиком -
EXISTS работает как semi-join и рано останавливается - Лучше масштабируется на больших данных
- Меньше сюрпризов с NULL
Особенно критично в PostgreSQL, MySQL и Oracle на больших таблицах.
👍6❤3🔥3🤔1
SQL хитрый совет для про 💡
Используй
❌ Как делают обычно:
✅ Как делают профи:
Почему это важно:
- меньше вычислений внутри агрегаций
- оптимизатору проще строить план
- код короче и легче поддерживать
- особенно эффективно в аналитических запросах
Где работает:
- PostgreSQL
- SQLite (частично)
- DuckDB
- ClickHouse (через аналоги)
Мелочь, но именно из таких мелочей складывается SQL уровня senior.
Используй
COUNT(*) FILTER вместо CASE WHEN — быстрее, чище и читаемее.❌ Как делают обычно:
SELECT
COUNT(CASE WHEN status = 'success' THEN 1 END) AS success_cnt,
COUNT(CASE WHEN status = 'error' THEN 1 END) AS error_cnt
FROM events;
✅ Как делают профи:
Копировать код
SELECT
COUNT(*) FILTER (WHERE status = 'success') AS success_cnt,
COUNT(*) FILTER (WHERE status = 'error') AS error_cnt
FROM events;
Почему это важно:
- меньше вычислений внутри агрегаций
- оптимизатору проще строить план
- код короче и легче поддерживать
- особенно эффективно в аналитических запросах
Где работает:
- PostgreSQL
- SQLite (частично)
- DuckDB
- ClickHouse (через аналоги)
Мелочь, но именно из таких мелочей складывается SQL уровня senior.
👍10❤3🔥1
Представь фэнтези-мир, где заклинания - это SQL-запросы, а древние артефакты спрятаны в таблицах и JSON-документах.
🧙Ты - боевой дата-аналитик, который с помощью SQL, Python, ETL и визуализаций охотится за харизматичным злодеем Архивариусом Пакостусом, что ломает индексы, крадёт данные и готовит “шторм данных” на столицу.🔮
В каждом эпизоде тебя ждут: выборы с последствиями, хитрые задачи от простых SELECT до рекурсивных CTE и BigQuery, юмор, эпик и неожиданные повороты.
Хочешь проверить, сможешь ли ты спасти королевство не мечом, а запросами? Тогда добро пожаловать в SQL-квест.
🪄 Начать квест: https://uproger.com/sql-kvest-fentezijnoe-priklyuchenie-dlya-analitikov-dannyh/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤4🔥1
Прокачай навыки на задачах, которые встречаются в реальной работе.
Бот в Telegram помогает тренироваться каждый день: задания обновляются, сложность растёт, а ошибки разбираются.
✔ практические кейсы
✔ удобный эмулятор работы Аналитика бесплатно
✔ пополняем задачами с реальных собеседований
✔ собираем фидбек и улучшаем тренажёр вместе с вами
Готов работать с данными уверенно? Попробуй симулятор и расти как аналитик.
t.me/Analitics_databot
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍4🔥2
PostgreSQL: архитектура и тюнинг SQL-запросов
Погрузись в архитектуру и прокачай оптимизацию запросов одной из самых популярных open source СУБД – PostgreSQL.
🌐 В программе курса:
🤩 Разберем, как работают СУБД вообще и PostgreSQL в частности: что такое MVCC, ACID, WAL, LRU, PPC/TPC и другие фундаментальные понятия архитектуры баз данных
🤩 Получите теорию и практику EXPLAIN и EXPLAIN ANALYZE на разных типа запросов: без индексов, с индексами, index only, нормализованные и документ-ориентированные данные и json-поля, изменение параметров сессии/конфигурации для ускорения запросов
🤩 Изучите архитектуру хранения данных в PostgreSQL, типы и особенности индексов, а также получите полезные советы и трюки оптимизации БД
🤩 Получите свой собственный выделенный облачный PostgreSQL-сервер (8 vCPU, 12G RAM, 100G NVMe) – предоставляется БЕСПЛАТНО на время обучения + готовый e-commerce датасет TPC-H (миллион пользователей, несколько миллионов заказов на десятки гигабайт)
🗓 Старт курса: 22 января. 5 недель обучения.
Изучить программу и записаться можно здесь.
🤩 Кто мы: R&D-центр Devhands, основатель школы Алексей Рыбак. Автор курса — Николай Ихалайнен, эксперт по СУБД (ex-Percona), со-основатель MyDB, энтузиаст открытого ПО.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2Vtzqug1BVk
Погрузись в архитектуру и прокачай оптимизацию запросов одной из самых популярных open source СУБД – PostgreSQL.
Изучить программу и записаться можно здесь.
Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2Vtzqug1BVk
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍4🖕1
💡 SQL-совет, который спасает от самой “хитрой” ошибки
Одна из самых коварных ситуаций в SQL - когда ты ожидаешь данные, а запрос возвращает 0 строк, хотя “всё правильно”.
Чаще всего причина - `NOT IN` + `NULL`.
Если в подзапросе есть хотя бы один
Правило:
- ❌ Не используй `NOT IN` с подзапросами
- ✅ Используй `NOT EXISTS` или
-- ❌ ПЛОХО: NOT IN ломается из-за NULL
-- ✅ ХОРОШО: NOT EXISTS безопасен
Одна из самых коварных ситуаций в SQL - когда ты ожидаешь данные, а запрос возвращает 0 строк, хотя “всё правильно”.
Чаще всего причина - `NOT IN` + `NULL`.
Если в подзапросе есть хотя бы один
NULL, то NOT IN ломает логику и не вернёт ничего.Правило:
- ❌ Не используй `NOT IN` с подзапросами
- ✅ Используй `NOT EXISTS` или
LEFT JOIN ... IS NULL-- ❌ ПЛОХО: NOT IN ломается из-за NULL
SELECT *
FROM users u
WHERE u.id NOT IN (
SELECT user_id
FROM banned_users
);
-- ✅ ХОРОШО: NOT EXISTS безопасен
SELECT *
FROM users u
WHERE NOT EXISTS (
SELECT 1
FROM banned_users b
WHERE b.user_id = u.id
);
👍8🔥5❤2