Инструмент форматирования SQL
Что такое форматирование SQL?
SQL Formatter структурирует SQL-запросы с едиными отступами, переносами строк и хорошо видимыми clauses. SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, CTE и подзапросы становится легче читать, что помогает ревью, отладке, обучению и анализу длинных отчетов. Форматирование также помогает заметить случайные cross join, перегруженные условия или неверно поставленные скобки. Оно не меняет логику базы данных, не оптимизирует execution plan, не гарантирует переносимость между MySQL, PostgreSQL, SQL Server и Oracle и не делает опасный dynamic SQL безопасным. Для production нужны проверки параметризации, прав, индексов, транзакций, блокировок и реального query plan.
Как использовать
Как использовать
- Вставьте или введите SQL-запросы в левое поле
- Выберите размер отступа (2 пробела, 4 пробела или табуляция) и регистр ключевых слов
- Нажмите «Форматировать» для приведения SQL в читаемый вид или «Минимизировать» для удаления пробелов
- Результат отображается справа с подсветкой синтаксиса
- Нажмите «Копировать» или «Скачать», чтобы сохранить результат
Примечания по проверке SQL
- Форматирование улучшает читаемость, но не проверяет права, индексы, планы выполнения и бизнес-корректность.
- Перед запуском изменённого SQL вручную проверьте конструкции, строковые литералы, комментарии и синтаксис, специфичный для вашей СУБД.
Применение
Технический принцип
Применение форматирования работает по одному правилу на предложение: SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT каждый начинается с новой строки в нулевой колонке, проектируемые столбцы и условия ON имеют отступ одного уровня (2 пробела, 4 пробела или табуляция), ключевые слова JOIN (INNER / LEFT / RIGHT / FULL / CROSS) выравниваются под FROM, CASE / WHEN / THEN / ELSE / END выстраиваются вертикально, а подзапросы в скобках и CTE, вложенные в WITH, получают дополнительный уровень отступа, чтобы внешний SELECT оставался визуально закреплённым. Строковые литералы, строчные комментарии (-- ...), блочные комментарии (/* ... */) и блоки в долларовых кавычках токенизируются один раз и копируются без изменений, поэтому внутренние пробелы никогда не затрагиваются.
Регистр ключевых слов применяется на этапе печати, а не через слепое регулярное выражение по исходному тексту — только токены, классифицированные как RESERVED_KEYWORD, преобразуются в верхний или нижний регистр, поэтому идентификатор 'order' или 'user' внутри обратных кавычек сохраняет свой оригинальный регистр. Поддержка диалектов важна, поскольку список зарезервированных слов различается в зависимости от СУБД: PostgreSQL распознаёт DISTINCT ON, RETURNING, ILIKE; MySQL добавляет IFNULL, LIMIT n,m, ENGINE=; SQL Server использует TOP n, OUTPUT, идентификаторы в квадратных скобках; Oracle добавляет DUAL, ROWNUM, MINUS вместо EXCEPT; BigQuery и Snowflake расширяют стандарт с помощью QUALIFY, EXCEPT (столбцы) и литералов массивов/структур. Производительность линейна относительно длины исходного текста (O(n) токенов, O(n) байт на выходе), поэтому даже миграционные скрипты размером в несколько мегабайт форматируются за миллисекунды.
- Токенизатор: сканирует исходный текст в классы RESERVED_KEYWORD, IDENTIFIER, STRING_LITERAL, NUMBER, OPERATOR, LINE_COMMENT (-- ...), BLOCK_COMMENT (/* ... */) и WHITESPACE; комментарии и строки сохраняются дословно
- Учёт диалекта: строки в одинарных кавычках (ANSI), идентификаторы в обратных кавычках (MySQL), идентификаторы в квадратных скобках (SQL Server), идентификаторы в двойных кавычках (PostgreSQL/стандарт), блоки в долларовых кавычках $$...$$ (PostgreSQL)
- Макет предложений: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT каждый закрепляется в колонке 0; проектируемые столбцы и условия ON имеют отступ одного уровня; ключевые слова JOIN выравниваются под FROM
- Отступы CTE и подзапросов: предложения WITH делают дополнительный отступ для внутреннего SELECT; коррелированные подзапросы внутри EXISTS / IN / скалярных контекстов получают собственный отступ, чтобы внешний запрос оставался закреплённым
- Политика регистра: применяется на этапе печати по классу токена — только токены RESERVED_KEYWORD переводятся в верхний/нижний регистр, поэтому идентификаторы вроде `order` или [user] сохраняют оригинальный регистр
- Параметры привязки: заполнители-знаки вопроса (подготовленные запросы MySQL), нумерованные привязки dollar-1/dollar-2 (PostgreSQL) и именованные привязки с двоеточием (Oracle/SQL*Plus) токенизируются как PARAMETER и никогда не переформатируются как идентификаторы
- Сложность: лексический анализ O(n) и печать O(n), где n — длина исходного текста; миграционные скрипты размером в несколько мегабайт форматируются за миллисекунды; сопоставимо с библиотекой sql-formatter npm, pgFormatter и плагином Prettier SQL
Примеры
Форматирование плотного SELECT с JOIN и WHERE
Вход: select u.id,u.name,o.total from users u left join orders o on o.user_id=u.id where u.status='active' and o.created_at>='2026-01-01' order by o.total desc limit 10;
Выход:
SELECT u.id, u.name, o.total
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.status = 'active'
AND o.created_at >= '2026-01-01'
ORDER BY o.total DESC
LIMIT 10;Минификация форматированного SQL для строки конфигурации
Вход (форматированный, 6 строк):
SELECT id, name
FROM products
WHERE price < 100
AND stock > 0
ORDER BY name;
Минифицированный выход (1 строка, 78 символов):
SELECT id,name FROM products WHERE price<100 AND stock>0 ORDER BY name;Форматирование WITH (CTE) с вложенным подзапросом
WITH recent_orders AS (
SELECT user_id, SUM(total) AS spend
FROM orders
WHERE created_at >= NOW() - INTERVAL '30 days'
GROUP BY user_id
)
SELECT u.name, r.spend
FROM users u
JOIN recent_orders r ON r.user_id = u.id
WHERE r.spend > (SELECT AVG(spend) FROM recent_orders);Ключевые слова в нижнем регистре (стиль команды)
Настройки: Отступ = 2 пробела, Ключевые слова = нижний регистр
Вход: SELECT * FROM Users WHERE Status=1;
Выход:
select *
from users
where status = 1;
Применение: соответствует стилю миграций Ruby on Rails / Django ORMЧасто задаваемые вопросы
Какие диалекты SQL поддерживаются?
Стандартный ANSI SQL плюс распространённые ключевые слова конкретных диалектов: MySQL, PostgreSQL, MSSQL/T-SQL, SQLite, Oracle, BigQuery, Snowflake. Выберите нужный диалект из выпадающего списка, чтобы форматтер знал о специфичных ключевых словах (LIMIT vs TOP, RETURNING, MERGE и т. д.).
Какие настройки стиля доступны?
Ключевые слова в верхнем или нижнем регистре, размер отступа, ведущие или замыкающие запятые в списках столбцов, максимальная длина строки для переноса, перенос до или после ключевых слов. Обычно эти параметры показаны на боковой панели.
Проверяет ли он SQL на корректность?
Большинство форматтеров парсят свободно и пропускают сомнительный SQL без изменений. Настоящая валидация требует подключения к базе (или хотя бы полноценного SQL-парсера вроде sqlparse, sqlglot). Используйте этот инструмент для оформления; для проверки синтаксиса — IDE или реальную БД.
Форматирует ли он хранимые процедуры и триггеры?
Большинство сборок поддерживают CREATE PROCEDURE / CREATE FUNCTION / триггеры в пределах возможностей диалекта. Очень длинные тела с управляющими конструкциями (IF/ELSE/WHILE) форматируются корректно; для расширений конкретных вендоров (специфичные ключевые слова T-SQL) нужно правильно выбрать диалект.
Загружается ли мой запрос на сервер?
Нет. Форматирование выполняется в браузере с помощью JavaScript-парсера SQL. Вставленный SQL никуда не передаётся. Тем не менее, никогда не вставляйте реальные продакшн-учётные данные или персональные данные ни в какой веб-инструмент.
Почему мои CTE и JOIN выглядят странно отступленными?
Разные форматтеры по-разному выравнивают CTE. Одни делают отступ для каждого определения CTE, другие оставляют их прижатыми влево. У JOIN тоже несколько допустимых стилей («JOIN x ON» против «JOIN x\n ON»). Выберите вариант, соответствующий стилю вашей команды, и придерживайтесь его.
Умеет ли он минифицировать SQL?
Некоторые сборки предлагают режим «в одну строку», убирающий переносы и лишние пробелы. Полезно при встраивании SQL в код в виде строкового литерала. Всегда храните в системе контроля версий отформатированную версию — однострочный SQL невозможно ревьюить.