5 SQL‑ошибок, которые продолжают ломать запросы даже у опытных аналитиков

Привет, коллеги! С вами снова Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

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

1️⃣ Использование SELECT * в продовых запросах

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

Например, у нас есть таблица с пользователями и транзакциями:

SELECT *
FROM transactions t
JOIN users u ON t.client_id = u.client_id

Сделать SELECT * для изучения и проверки — правильное решение, но записывать такую конструкцию в созданную таблицу нельзя. Если в таблицу users добавят поле с большим текстом — например, выводы ИИ о клиенте — то во-первых, запрос сломается, так как появится новое поле. А во-вторых, если заменили содержимое существующего поля, то запрос внезапно станет в 10 раз тяжелее.

Правильно отбирать только нужные столбцы:

SELECT t.client_id, t.amount, u.segment
FROM transactions t
JOIN users u ON t.client_id = u.client_id

2️⃣ Неправильная работа с NULL в условиях

NULL — это не значение, это пустота. И многие забывают, что сравнения с NULL работают иначе, чем сравнение с заполненными полями.

Например, вам нужно отобрать всех клиентов, кроме клиентов с тестовым емейлом. Если написать:

WHERE email <> ‘test@example.com’

То строки, где email = NULL, не попадут в выборку, хотя логически должны. Это частая ошибка, на которой ловят новичков. Чтобы правильно отобрать клиентов, используйте:

WHERE email <> ‘test@example.com’ OR email IS NULL

или

WHERE nvl(email, ‘N/A’) <> ‘test@example.com’

3️⃣ Фильтрация после JOIN вместо фильтрации до JOIN

Очень часто нам нужно объединить таблицы и отфильтровать их одновременно. Многие начинающие аналитики делают так:

SELECT *
FROM users u
LEFT JOIN transactions t ON u.client_id = t.client_id
WHERE t.amount > 100

Фильтр превращает LEFT JOIN в INNER JOIN и убивает значения из таблицы users, так как отфильтровывает все данные после объединения. Но пользователи без транзакций вам тоже нужны. Чтобы сделать правильный запрос и ничего не потерять, используйте фильтрацию внутри JOIN:

LEFT JOIN transactions t 
    ON u.client_id = t.client_id
    AND t.amount > 100

Это не только правильно, но и оптимально с точки зрения производительности.

4️⃣ Использование HAVING вместо WHERE

Путаница между WHERE и HAVING — это вечная проблема. Запомните, HAVING — это фильтр после группировки. Давайте рассмотрим на примере:

SELECT employee_id, SUM(salary)
FROM salary
GROUP BY employee_id
HAVING SUM(salary) > 1000

В данном запросе результат будет покажет только сотрудников с общей зарплатой более 1000 за весь период. То есть фильтрация будет после агрегации. Но если вам нужны только те сотрудники, которые каждый месяц получают более 1000, то есть условие до агрегации, то вам нужно использовать:

SELECT employee_id, SUM(salary)
FROM salary
WHERE salary > 1000
GROUP BY employee_id

Выглядит похоже, но смысл совершенно разный.

5️⃣ Использование UNION вместо UNION ALL

UNION, в отличие от UNION ALL, сверяет все строки и удаляет дубли. Поэтому использование UNION значительно замедляет запрос. Если вам не нужно удалять дубли, то не пишите:

SELECT client_id FROM table1
UNION
SELECT client_id FROM table2

Вместо этого используйте:

SELECT client_id FROM table1
UNION ALL
SELECT client_id FROM table2

Ставьте 🔥, если было полезно, и сохраняйте к себе, чтобы не допускать эти ошибки!

📈 Симулейтив | ВК | YouTube