Форматирование SQL: соглашения, диалекты и отладка запросов

Каждый разработчик бывал в такой ситуации. Вы извлекаете медленный запрос из логов приложения, копируете его в редактор — и видите перед собой стену из 300 символов строчных букв без пробелов, без переносов строк и без малейшей пощады. Или находите ответ на Stack Overflow с нужным запросом, но он написан в одну строку. Или ORM любезно логирует генерируемый SQL — единой конкатенированной строкой. Во всех этих случаях запрос технически корректен, но практически нечитаем.

Форматирование SQL — это не эстетика. Это способность понять, что делает запрос с первого взгляда: из каких таблиц он читает данные, по каким условиям фильтрует и какие столбцы возвращает. Хорошо отформатированный запрос можно проверить, отладить и оптимизировать за минуты. Неотформатированный способен украсть часы.

SQL-форматтер BrowseryTools позволяет вставить любой запрос и мгновенно отформатировать его с правильными отступами, ключевыми словами в верхнем регистре и разбивкой по предложениям — всё обрабатывается локально в браузере, ни один запрос не отправляется на сервер.

Почему неотформатированный SQL так мучителен

SQL — один из немногих языков, в котором разработчики регулярно работают с кодом, который не писали сами и не могут переформатировать в источнике. Три самых распространённых источника «уродливого» SQL:

• Запросы, сгенерированные ORM. Hibernate, SQLAlchemy, ActiveRecord и их аналоги генерируют SQL динамически. Когда вы включаете логирование запросов для отладки производительности, вы получаете сырой SQL — как правило, в одну строку с динамическими значениями параметров, алиасами типа t0_ и условиями JOIN, которые нужно перечитать несколько раз, чтобы разобраться.
• Логи запросов из production-баз данных. Лог медленных запросов MySQL иpg_stat_statements в PostgreSQL хранят запросы в том виде, в каком они были отправлены — без какого-либо форматирования. Они бесценны для анализа производительности, но практически нечитаемы без предварительного переформатирования.
• Однострочные примеры из Stack Overflow и документации. Код в ответах и документации часто сжимают в одну строку для экономии вертикального пространства. Логика верна, но компоновка затрудняет адаптацию к собственной схеме.

До и после: один и тот же запрос, отформатированный

Вот реалистичный запрос в том виде, в каком он может появиться в логе медленных запросов или в выводе ORM — всё в одну строку, ключевые слова в нижнем регистре:

select u.id,u.name,u.email,count(o.id) as order_count,sum(o.total) as total_spent from users u left join orders o on u.id=o.user_id where u.created_at>='2024-01-01' and u.status='active' group by u.id,u.name,u.email having count(o.id)>0 order by total_spent desc limit 20;

После форматирования с соблюдением принятых соглашений SQL тот же запрос становится немедленно читаемым:

SELECT
    u.id,
    u.name,
    u.email,
    COUNT(o.id)  AS order_count,
    SUM(o.total) AS total_spent
FROM users AS u
LEFT JOIN orders AS o
    ON u.id = o.user_id
WHERE u.created_at >= '2024-01-01'
  AND u.status = 'active'
GROUP BY
    u.id,
    u.name,
    u.email
HAVING COUNT(o.id) > 0
ORDER BY total_spent DESC
LIMIT 20;

Структура теперь очевидна мгновенно: вы видите, что это пользовательский отчёт, выбирающий количество заказов и сумму трат, отфильтрованный по активным пользователям с 2024 года, сгруппированный по пользователям и ограниченный топ-20 по расходам. На понимание ушло пять секунд — вместо пяти минут.

Соглашения форматирования SQL

Официального руководства по стилю SQL не существует, однако в отрасли сложился набор широко принятых соглашений. Их соблюдение делает SQL читаемым для любого разработчика, знакомого с языком.

Ключевые слова в верхнем регистре

Ключевые слова SQL — SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, HAVING, LIMIT, INSERT, UPDATE, DELETE, WITH, AS, AND, OR, NOT, IN, LIKE, BETWEEN, IS NULL — должны быть в верхнем регистре. Имена таблиц, столбцов, алиасы и строковые литералы остаются в своём естественном регистре. Этот визуальный контраст между КЛЮЧЕВЫМИ СЛОВАМИ и идентификаторами делает запросы читаемыми с первого взгляда.

Каждое основное предложение — на отдельной строке

Каждое предложение верхнего уровня начинается с новой строки: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. Это создаёт чёткий визуальный скелет запроса. Открывая отформатированный запрос, взгляд сразу находит каждое предложение, так как все они начинаются от левого края (или на постоянном уровне отступа).

Отступы для списков столбцов и условий

Имена столбцов в списке SELECT и условия в WHERE отображаются с отступом в четыре пробела (или один символ табуляции). Каждый оператор ANDи OR в предложении WHERE начинается на новой строке на том же уровне отступа, что и первое условие — это делает тривиальным добавление, удаление и комментирование отдельных условий:

WHERE u.created_at >= '2024-01-01'
  AND u.status = 'active'
  AND u.country IN ('US', 'CA', 'GB')

Расстановка запятых: два подхода

Дискуссия о размещении запятых в SQL похожа на споры о trailing-запятых в JavaScript. Существуют два допустимых стиля:

• Завершающие запятые (запятая в конце каждой строки): наиболее распространённый стиль, совпадающий с тем, как большинство разработчиков пишут списки на других языках. Недостаток: при комментировании последнего элемента нужно также убирать запятую у предыдущего.
• Запятая в начале строки (запятая перед элементом, начиная со второго): упрощает комментирование любой строки без изменения соседних. Предпочитается командами, которые часто модифицируют списки столбцов в процессе разработки.

Оба варианта допустимы. Выберите один и придерживайтесь его в рамках проекта. SQL-форматтер BrowseryTools использует завершающие запятые по умолчанию — это согласуется с большинством руководств по стилю и является ожидаемым соглашением для большинства читателей.

Выровненные алиасы с AS

Всегда используйте явный AS для алиасов — никогда неявный стиль без слова, который допускают некоторые диалекты (COUNT(o.id) order_count). Когда в списке SELECT несколько алиасов, выравнивание ключевого слова ASпо одному столбцу делает список читаемым с первого взгляда:

SELECT
    COUNT(o.id)      AS order_count,
    SUM(o.total)     AS total_spent,
    AVG(o.total)     AS average_order,
    MAX(o.created_at) AS last_order_date

Как читать сложный запрос с несколькими JOIN

Столкнувшись с запросом, содержащим три, четыре или пять JOIN, не начинайте с начала. Начинайте с предложения FROM. Оно говорит о главной таблице — точке опоры запроса. Каждый последующий JOIN добавляет ещё одну таблицу к результирующему набору, а условие ON показывает, как строки этой таблицы связаны со строками, уже накопленными до этого. Только разобравшись с моделью данных через FROM и JOIN, стоит возвращаться к SELECT, чтобы посмотреть, какие столбцы возвращаются, затем к WHERE для фильтрации и к GROUP BY для агрегации.

Порядок чтения любого SELECT-запроса: FROM → JOIN(s) → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT. Он совпадает с тем, как движок базы данных фактически обрабатывает предложения, и соответствует логике рассуждений о данных, проходящих через каждый шаг.

Форматирование подзапросов

Подзапросы — запросы, вложенные внутрь другого запроса — заслуживают собственного уровня отступа. Каждый уровень вложенности добавляет один уровень отступа, и структура остаётся чёткой даже при двух-трёх уровнях вложенности:

SELECT
    u.id,
    u.name,
    u.email
FROM users AS u
WHERE u.id IN (
    SELECT DISTINCT o.user_id
    FROM orders AS o
    WHERE o.total > 500
      AND o.created_at >= '2024-01-01'
)
ORDER BY u.name;

Внутренний запрос явно подчинён внешнему. Закрывающая скобка выровнена с ключевым словом (WHERE), которое ввело подзапрос. Для глубоко вложенных или сложных подзапросов CTE (Common Table Expressions) почти всегда предпочтительнее, поскольку им можно дать имена и разместить в начале запроса, где их легко читать.

Типичные паттерны запросов и их отформатированный вид

INSERT INTO ... SELECT

INSERT INTO order_archive (
    id,
    user_id,
    total,
    created_at
)
SELECT
    id,
    user_id,
    total,
    created_at
FROM orders
WHERE created_at < '2023-01-01';

UPDATE с JOIN (синтаксис MySQL / SQL Server)

UPDATE users AS u
JOIN subscriptions AS s
    ON u.id = s.user_id
SET u.plan = s.plan_name,
    u.plan_updated_at = NOW()
WHERE s.status = 'active'
  AND s.updated_at >= '2024-01-01';

Запрос WITH (CTE)

Common Table Expressions — наиболее мощный инструмент форматирования в SQL. Они позволяют давать имена промежуточным наборам результатов, превращая глубоко вложенный запрос в серию чётко именованных шагов:

WITH active_users AS (
    SELECT id, name, email
    FROM users
    WHERE status = 'active'
      AND created_at >= '2024-01-01'
),
user_orders AS (
    SELECT
        user_id,
        COUNT(id)  AS order_count,
        SUM(total) AS total_spent
    FROM orders
    GROUP BY user_id
)
SELECT
    au.id,
    au.name,
    au.email,
    uo.order_count,
    uo.total_spent
FROM active_users AS au
LEFT JOIN user_orders AS uo
    ON au.id = uo.user_id
ORDER BY uo.total_spent DESC
LIMIT 20;

Почему форматирование важно для анализа производительности

Форматирование — это не только читаемость для людей: оно делает проблемы производительности видимыми. После того как запрос правильно оформлен, ряд классов проблем становится легко заметным:

• Отсутствующие индексы. Отформатированное предложение WHEREсо всеми условиями на отдельных строках позволяет легко проверить, что для каждого столбца-условия есть индекс. В неотформатированной однострочной записи условия легко пропустить.
• Декартовы произведения. JOIN без условия ON (или с всегда-истинным условием) создаёт перекрёстное соединение, умножающее количество строк. Когда каждый JOIN расположен на отдельной строке с условиемON с отступом под ним, отсутствующее условие сразу бросается в глаза.
• Паттерны N+1 запросов. Когда видно, что запрос выбирает список идентификаторов в подзапросе, а затем снова соединяется с той же таблицей, — это сигнал, что запрос можно переписать с прямым JOIN, устраняя проблему N+1 на уровне SQL, а не в коде приложения.
• Функции на индексируемых столбцах. WHERE DATE(created_at) = '2024-01-01' мешает базе данных использовать индекс по created_at. В отформатированном запросе этот паттерн заметен сразу; в однострочной записи — незаметен.

Диалекты SQL: важные синтаксические различия

SQL — это стандарт (ISO/IEC 9075), но каждая крупная база данных расширяет его диалектно-специфичным синтаксисом. Вот что важно для форматирования:

PostgreSQL: двойные кавычки и чувствительность к регистру

В PostgreSQL идентификаторы без кавычек приводятся к нижнему регистру. Если таблица была создана как CREATE TABLE "UserProfiles" (в двойных кавычках), ссылаться на неё всегда нужно как "UserProfiles" с кавычками. Без кавычек PostgreSQL ищет userprofiles и возвращает ошибку. Это частый источник путаницы при миграции с MySQL или при работе с ORM, генерирующими имена в смешанном регистре.

MySQL: экранирование обратными кавычками

MySQL использует обратные кавычки для экранирования идентификаторов, а не двойные (хотя MySQL в режиме ANSI_QUOTES принимает и двойные кавычки). Обратные кавычки встречаются в DDL, сгенерированном MySQL, и в запросах, экспортированных инструментами вроде phpMyAdmin. SQL-форматтер обрабатывает идентификаторы в обратных кавычках и сохраняет их, чтобы результат оставался корректным для вашей конкретной базы.

Как использовать SQL-форматтер BrowseryTools

Использование форматтера занимает три шага:

• Вставьте запрос. Скопируйте сырой SQL из лог-файла, вывода ORM или редактора и вставьте в поле ввода. Форматтер принимает любой объём SQL — одиночные операторы, несколько операторов или целые скрипты.
• Нажмите «Форматировать». Форматтер применяет ключевые слова в верхнем регистре, разбивку по предложениям, отступы и единообразные пробелы. Результат появляется в панели вывода мгновенно — без сетевых запросов и задержек.
• Скопируйте результат. Нажмите кнопку «Копировать», чтобы поместить отформатированный SQL в буфер обмена — готов для вставки в редактор, клиент базы данных или pull request.

Поскольку форматтер работает полностью в браузере, вы можете безопасно вставлять запросы с конфиденциальными данными — production-именами таблиц, идентификаторами клиентов, внутренними деталями схемы — без риска их утечки. Никакого бэкенда для логирования запросов не существует.

Форматируйте SQL-запросы прямо сейчас

Распутываете ли вы монстра, созданного ORM, проверяете pull request коллеги, отлаживаете медленный запрос или просто пытаетесь понять, что на самом деле делает ответ с Stack Overflow, — отформатированный SQL делает каждую из этих задач быстрее и менее подверженной ошибкам. Хорошее форматирование — дешевейшая оптимизация производительности, доступная до того, как вы возьмётесь за EXPLAIN.