Короткий ответ
Кроме синтаксической корректности нужно проверить логическую корректность (нет ли задвоения строк из-за JOIN, правильно ли обрабатываются NULL и дубликаты), читаемость и поддерживаемость запроса, а также его производительность на реальном объёме данных.
Как это работает подробнее
- Как это работает: код-ревью SQL — это не только «запрос выполнился», а проверка, что результат соответствует бизнес-смыслу вопроса: например, JOIN с таблицей «один ко многим» может задвоить суммы, если не агрегировать результат правильно.
Пример кода
average_order_value.sql
SELECT AVG(o.amount)
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
WHERE o.created_at::date = '2024-05-01';
SELECT AVG(sub.amount)
FROM (
SELECT DISTINCT o.id, o.amount
FROM orders o
JOIN order_items oi ON oi.order_id = o.id
WHERE o.created_at >= '2024-05-01' AND o.created_at < '2024-05-02'
) sub;Что использовать на практике
- На практике: ревьюер смотрит на наличие алиасов и форматирование (легко ли читать JOIN-условия), проверяет, есть ли явный список столбцов вместо
SELECT *, обоснованность использованияDISTINCT(часто это «затычка» для скрытия задвоения, а не осознанное решение), обработку NULL в агрегатах и фильтрах, и примерный план выполнения (EXPLAIN) на проде, если таблицы большие. - Пример и проверка. Проблемный запрос: Если у заказа несколько позиций, o.amount задвоится по числу строк в order_items. Исправление: Проверка: сравнить COUNT(DISTINCT o.id) из исходного и исправленного запроса — числа заказов должны совпадать, а средний чек в исправленной версии не должен зависеть от количества позиций в заказе.
Подводные камни
- Частые ошибки: автор запроса джойнит таблицу заказов с таблицей позиций заказа и считает
AVG(orders.amount)без агрегации по заказу, получая задвоенные и искажённые суммы; использованиеDISTINCT *вместо исправления причины дублей; фильтрация по дате строкой без приведения типов, из-за чего индекс по дате не используется и запрос работает намного медленнее, чем мог бы.