SQL anti-patterns на собеседовании Data Engineer

Зачем разбирать на собесе

SQL anti-patterns — частая боль производительности. На собесе DE: «что плохого в этом запросе».

SELECT *

-- bad
SELECT * FROM users WHERE id = 42;

-- good
SELECT id, name, email FROM users WHERE id = 42;

Why bad:

• Network bandwidth wasted.
• Может break на schema change (extra column → app crashes).
• Index Only Scan невозможен (если covering index).

Function on indexed column

-- bad: index не используется
WHERE LOWER(email) = 'a@b.com'

-- good: functional index или нормализация при insert
CREATE INDEX idx ON users(LOWER(email));
WHERE LOWER(email) = 'a@b.com'

Функция destroys index ability.

Аналогично: WHERE date(created_at) = '2026-05-07' — bad. WHERE created_at >= '2026-05-07' AND created_at < '2026-05-08' — good.

Implicit type casts

-- bad: id INT, передаётся string → implicit cast
WHERE id = '42'

-- good
WHERE id = 42

Implicit cast может break index usage (especially в MySQL).

N+1 queries

App pattern.

users = db.query("SELECT * FROM users")  # 1
for user in users:
    orders = db.query("SELECT * FROM orders WHERE user_id = ?", user.id)  # N

1 + N queries instead of 1.

Fix.

SELECT u.*, o.* FROM users u LEFT JOIN orders o ON o.user_id = u.id;

Или separate query c IN.

OR vs UNION

-- иногда плохо
WHERE x = 1 OR y = 2

-- лучше для optimizer
SELECT ... WHERE x = 1
UNION
SELECT ... WHERE y = 2

OR между different columns часто prevents index usage. UNION — combines two index scans.

Связанные темы

• EXPLAIN и план запроса для DE
• Query optimization для DE
• Индексы БД для DE
• Anti и semi joins для DE
• Подготовка к собесу Data Engineer

FAQ

Это официальная информация?

Нет. Статья основана на индустриальном опыте.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.