Outil de Formatage SQL
Qu'est-ce que le formatage SQL ?
Le formateur SQL structure les requêtes avec indentation, retours à la ligne et clauses clairement visibles. SELECT, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, CTEs et sous-requêtes deviennent plus faciles à lire, ce qui aide revues, débogage, formation et analyse de longs rapports. Le formatage peut aussi révéler jointures croisées accidentelles, conditions trop denses ou parenthèses mal placées. Il ne change pas la logique de base, n’optimise pas les plans d’exécution, ne garantit pas la portabilité entre dialectes et ne sécurise pas du SQL dynamique dangereux. En production, paramètres, permissions, index, transactions, verrouillage et plan réel doivent être examinés.
Mode d'emploi
Mode d'emploi
- Collez ou saisissez les instructions SQL dans la zone de saisie de gauche.
- Choisissez la taille d'indentation (2 espaces, 4 espaces ou Tab) et la casse des mots-clés.
- Cliquez sur « Formater » pour embellir le SQL ou sur « Minifier » pour supprimer les espaces.
- Le résultat s'affiche à droite avec coloration syntaxique.
- Cliquez sur « Copier » ou « Télécharger » pour enregistrer le résultat.
Conseils pour la revue SQL
- Le formatage améliore la lisibilité mais ne vérifie ni les permissions, ni les index, ni les plans d'exécution, ni la logique métier.
- Avant d'exécuter un SQL modifié, relisez manuellement les clauses générées, les littéraux de chaîne, les commentaires et la syntaxe propre à votre base.
Cas d’utilisation
Principe technique
La passe d'impression applique une règle par clause : SELECT / FROM / WHERE / GROUP BY / HAVING / ORDER BY / LIMIT commencent chacun une nouvelle ligne à la colonne zéro, les colonnes projetées et les conditions ON s'indentent d'un niveau (2 espaces, 4 espaces ou une tabulation), les mots-clés JOIN (INNER / LEFT / RIGHT / FULL / CROSS) s'alignent sous FROM, CASE / WHEN / THEN / ELSE / END sont empilés verticalement, et les sous-requêtes entre parenthèses et les CTE imbriquées dans WITH reçoivent un niveau d'indentation supplémentaire afin que le SELECT externe reste visuellement ancré. Les littéraux de chaîne, les commentaires de ligne (-- ...), les commentaires de bloc (/* ... */) et les blocs délimités par des dollars sont analysés une seule fois et copiés tels quels, de sorte que l'espacement interne n'est jamais modifié.
La conversion de casse des mots-clés est appliquée au moment de l'impression, et non par une expression régulière aveugle sur le source — seuls les jetons classés comme RESERVED_KEYWORD sont convertis en majuscules ou minuscules, de sorte qu'un identifiant appelé 'order' ou 'user' entre backticks conserve sa casse d'origine. La prise en charge du dialecte est importante car la liste des mots réservés diffère selon le moteur : PostgreSQL reconnaît DISTINCT ON, RETURNING, ILIKE ; MySQL ajoute IFNULL, LIMIT n,m, ENGINE= ; SQL Server utilise TOP n, OUTPUT, les identifiants entre crochets ; Oracle ajoute DUAL, ROWNUM, MINUS en remplacement de EXCEPT ; BigQuery et Snowflake étendent le standard avec QUALIFY, EXCEPT (colonnes) et les littéraux array/struct. La performance est linéaire par rapport à la longueur du source (O(n) jetons, O(n) octets en sortie), de sorte que même des scripts de migration de plusieurs mégaoctets sont formatés en millisecondes.
- Analyseur lexical : découpe le source en classes RESERVED_KEYWORD, IDENTIFIER, STRING_LITERAL, NUMBER, OPERATOR, LINE_COMMENT (-- ...), BLOCK_COMMENT (/* ... */) et WHITESPACE ; les commentaires et chaînes sont préservés verbatim
- Conscience du dialecte : chaînes entre guillemets simples (SQL standard), identifiants entre backticks (MySQL), identifiants entre crochets (SQL Server), identifiants entre guillemets doubles (PostgreSQL/standard), blocs délimités par des dollars $$...$$ (PostgreSQL)
- Disposition des clauses : SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT s'ancrent chacun à la colonne 0 ; les colonnes projetées et les conditions ON s'indentent d'un niveau ; les mots-clés JOIN s'alignent sous FROM
- Indentation des CTE et sous-requêtes : les clauses WITH indentent le SELECT interne d'un niveau supplémentaire ; les sous-requêtes corrélées dans les contextes EXISTS / IN / scalaires reçoivent leur propre indentation afin que la requête externe reste ancrée
- Politique de casse : appliquée au moment de l'impression par classe de jeton — seuls les jetons RESERVED_KEYWORD sont mis en majuscules/minuscules, de sorte que les identifiants comme `order` ou [user] conservent leur casse d'origine
- Paramètres liés : espaces réservés point d'interrogation (requêtes préparées MySQL), liens numérotés dollar-1/dollar-2 (PostgreSQL) et liens nommés deux-points (Oracle/SQL*Plus) sont analysés comme PARAMETER et jamais reformatés en tant qu'identifiants
- Complexité : analyse lexicale O(n) et impression O(n) où n = longueur du source — les scripts de migration de plusieurs mégaoctets sont formatés en millisecondes ; comparable à la bibliothèque npm sql-formatter, pgFormatter et le plugin Prettier SQL
Exemples
Formater un SELECT compact avec JOIN et WHERE
Entrée : 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;
Sortie :
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;Minifier du SQL formaté pour une chaîne de configuration
Entrée (formatée, 6 lignes) :
SELECT id, name
FROM products
WHERE price < 100
AND stock > 0
ORDER BY name;
Sortie minifiée (1 ligne, 78 caractères) :
SELECT id,name FROM products WHERE price<100 AND stock>0 ORDER BY name;Formatage WITH (CTE) + sous-requête imbriquée
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);Mots-clés en minuscules (style d'équipe)
Paramètres : Indentation = 2 espaces, Mots-clés = minuscules
Entrée : SELECT * FROM Users WHERE Status=1;
Sortie :
select *
from users
where status = 1;
Utilisation : correspond aux fichiers de migration de style ORM Ruby on Rails / DjangoFAQ
Quels dialectes SQL sont pris en charge ?
ANSI SQL standard plus les mots-clés spécifiques courants : MySQL, PostgreSQL, MSSQL/T-SQL, SQLite, Oracle, BigQuery, Snowflake. Choisissez votre dialecte cible dans le menu déroulant pour que le formateur connaisse les mots-clés spécifiques (LIMIT vs TOP, RETURNING, MERGE, etc.).
Quelles options de style sont disponibles ?
Mots-clés en majuscules ou minuscules, taille d'indentation, virgules en tête ou en fin de ligne dans les listes de colonnes, longueur de ligne max pour le retour à la ligne, et césure avant ou après les mots-clés. La page affiche généralement ces options dans un panneau latéral.
Le SQL est-il validé ?
La plupart des formateurs analysent de manière souple et laissent passer le SQL douteux tel quel. Une vraie validation nécessite une connexion à la base (ou au moins un vrai parseur SQL comme sqlparse, sqlglot). Utilisez cet outil pour la mise en forme ; utilisez votre IDE ou la base réelle pour la vérification syntaxique.
Formatera-t-il les procédures stockées et les triggers ?
La plupart des builds gèrent CREATE PROCEDURE / CREATE FUNCTION / triggers dans les limites du dialecte. Les corps très longs avec contrôle de flux (IF/ELSE/WHILE) sont formatés correctement ; les extensions propriétaires (mots-clés T-SQL spécifiques) requièrent le bon dialecte.
Ma requête est-elle envoyée ?
Non. Le formatage s'exécute dans votre navigateur avec un parseur SQL JavaScript. Le SQL collé n'est pas transmis. Cela dit, ne collez jamais de vrais identifiants de production ou des données personnelles dans un outil web.
Pourquoi mes CTE et jointures sont-ils indentés bizarrement ?
Les formateurs ne s'accordent pas sur l'alignement des CTE. Certains indentent chaque définition de CTE ; d'autres les laissent collées à gauche. Les jointures aussi ont plusieurs styles valides (« JOIN x ON » vs « JOIN x\n ON »). Choisissez l'option qui correspond au style de votre équipe et tenez-vous-y.
Peut-il minifier le SQL ?
Certaines versions proposent un mode « une seule ligne » qui supprime les retours à la ligne et les espaces superflus. Utile pour intégrer du SQL dans du code sous forme de chaîne littérale. Conservez toujours la version formatée dans le contrôle de version : le SQL sur une ligne est illisible en revue de code.