Какие сложности возникают при написании SQL-запросов
Что проверяют
Для тестировщика SQL это инструмент проверки: найти запись, сверить результат операции с базой, подготовить данные. Интервьюер хочет понять, на чём вы уже обжигались и не получите ли ложный «зелёный» из-за кривого запроса. Следом часто просят написать запрос с JOIN и GROUP BY прямо на собеседовании.
Как отвечать
Называйте не опечатки, которые подсветит любой клиент базы, а логические ловушки, где запрос выполняется, но врёт:
- размножение строк в
JOIN: соединение «один ко многим» дублирует строки, иSUMпо заказам вдруг удваивается. Сверяйте число строк до и после соединения; NULL:WHERE col = NULLне вернёт ничего, нужноIS NULL.NOT INс подзапросом, где встречаетсяNULL, возвращает пустоту, надёжнееNOT EXISTS.COUNT(col)пропускаетNULL, в отличие отCOUNT(*);LEFT JOINс условием вWHERE: фильтр по правой таблице вWHEREпревращает его в обычныйINNER JOIN, условие нужно переносить вON;WHEREпротивHAVING: фильтр по агрегату работает только вHAVING;- даты и время:
BETWEEN '2026-09-01' AND '2026-09-30'по колонкеtimestampтеряет весь последний день, плюс расхождение часовых поясов между приложением и базой; - диалекты:
LIMITв PostgreSQL и MySQL,TOPв SQL Server, стандартныйFETCH FIRST n ROWS ONLYв Oracle и PostgreSQL; - общий стенд: тяжёлый запрос без индекса тормозит всем, а
UPDATEбезWHEREпортит данные коллегам. Меняйте данные в транзакции: сначалаSELECTс тем же условием, потом изменение, и только затемCOMMIT.
Если приложение ходит в базу через ORM, полезно уметь достать реальный SQL из логов и сравнить его со своим проверочным запросом.
Где спотыкаются
Считают, что раз запрос отработал без ошибки, результат верный. Самые дорогие ошибки как раз молчаливые: дубли после JOIN и потерянные NULL.
Проверяют результат теста тем же запросом, что написал разработчик. Если в логике ошибка, проверка её повторит и пройдёт.
Не могут объяснить разницу между DELETE, TRUNCATE и откатом транзакции, хотя чистка тестовых данных входит в ежедневную работу.