Форматирование SQL

RSS

Превращайте длинный и неаккуратный SQL в аккуратные запросы с отступами для MySQL, PostgreSQL, SQL Server, SQLite, BigQuery и других СУБД.

Работает на 100% в вашем браузере. Ничего из вставленного не загружается на сервер и не сохраняется.
SQL-запрос
Отформатированный SQL
Готово.

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

  1. Вставьте один или несколько SQL-запросов в поле ввода.
  2. Выберите диалект, соответствующий вашей базе данных: стандартный SQL, MySQL, PostgreSQL, SQL Server (T-SQL), SQLite, MariaDB, BigQuery, Snowflake или Oracle PL/SQL.
  3. В поле Ключевые слова выберите регистр: «ВЕРХНИЙ РЕГИСТР», «нижний регистр» или «Как есть».
  4. Задайте отступ.
  5. Нажмите кнопку Форматировать SQL и скопируйте результат.

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

Зачем форматировать SQL?

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

Форматировщик помещает каждое основное предложение (SELECT, FROM, JOIN, WHERE, GROUP BY, ORDER BY) на отдельную строку и единообразно расставляет отступы для вложенных частей. Сравните:

select u.id,u.email,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.created_at>='2026-01-01' group by u.id,u.email having count(o.id)>5 order by orders desc;
SELECT
  u.id,
  u.email,
  COUNT(o.id) AS orders
FROM
  users u
  LEFT JOIN orders o ON o.user_id = u.id
WHERE
  u.created_at >= '2026-01-01'
GROUP BY
  u.id,
  u.email
HAVING
  COUNT(o.id) > 5
ORDER BY
  orders DESC;

Отформатированный вариант проще проверять в pull request, проще отлаживать, и он даёт более чистые диффы, когда кто-то позже добавляет столбец или условие.

Почему важен диалект

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

ДиалектКавычки идентификаторовПримеры специфичного синтаксиса
MySQL / MariaDB`backticks`LIMIT 10, ON DUPLICATE KEY UPDATE
PostgreSQL"double quotes"приведение типов ::, RETURNING, ILIKE
SQL Server (T-SQL)[brackets]SELECT TOP 10, @variables
BigQuery`backticks`STRUCT, UNNEST, EXCEPT в SELECT *
Oracle PL/SQL"double quotes"FETCH FIRST 10 ROWS ONLY, блоки BEGIN … END;

Если запрос форматируется странно, например оператор разрывается или ключевое слово воспринимается как имя столбца, обычно помогает переключение на правильный диалект.

Частые ошибки в SQL, которые помогает заметить форматирование

Форматировщик не выполняет и не проверяет запрос полностью, но понятное оформление делает многие ошибки очевидными:

  • Пропущенная запятая в списке выборки. SELECT id name FROM users — допустимый SQL, но он возвращает id под псевдонимом name. Когда в каждой строке по одному столбцу, пропущенная запятая бросается в глаза.
  • Фильтр по таблице внешнего соединения в WHERE. LEFT JOIN orders o … WHERE o.status = 'paid' незаметно превращает внешнее соединение во внутреннее. Если нужно сохранить строки без совпадений, перенесите условие в предложение ON.
  • Смесь AND и OR без скобок. AND связывает сильнее, чем OR, поэтому a OR b AND c означает a OR (b AND c). Добавьте скобки, чтобы явно показать намерение.
  • Несбалансированные скобки или кавычки. Если отступы в результате внезапно «уплывают», ищите незакрытую скобку или строковый литерал прямо перед этим местом.

Советы и лучшие практики

  • Ключевые слова в верхнем регистре — распространённое соглашение, потому что они отделяют синтаксис SQL от названий таблиц и столбцов; нижний регистр так же допустим. Выберите один вариант для проекта.
  • Всегда задавайте псевдонимы таблиц в запросах с несколькими таблицами и уточняйте имена столбцов (u.id, а не id).
  • Никогда не собирайте SQL конкатенацией пользовательского ввода. Используйте параметризованные запросы или подготовленные выражения, чтобы предотвратить SQL-инъекции.
  • Храните метки времени в виде целых чисел? Воспользуйтесь конвертером Unix-времени, чтобы узнать, что означает значение, и генератором UUID для тестовых первичных ключей.
Совет: Форматируете результат запроса, хранящийся в JSON? Вставьте его в форматирование и валидацию JSON.

Часто задаваемые вопросы

Меняет ли форматирование то, что делает мой запрос?

Нет. Форматировщик меняет только пробелы, переносы строк и, если вы выберете, регистр ключевых слов. Идентификаторы, строковые литералы и логика запроса остаются прежними.

Проверяет ли форматирование SQL, корректен ли мой запрос?

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

Можно ли форматировать несколько запросов сразу?

Да. Разделяйте запросы точками с запятой, и каждый из них будет отформатирован по очереди.

Должны ли ключевые слова SQL быть в верхнем регистре?

Ключевые слова SQL не зависят от регистра во всех основных базах данных, так что это исключительно вопрос стиля. Верхний регистр традиционен и часто встречается в документации; многие современные команды предпочитают нижний. Главное — единообразие.

Обновлено

Скопировано в буфер обмена