Collez une requête SQL minifiée et obtenez une sortie lisible et indentée. Choisissez le dialecte, la largeur d'indentation et la casse des mots-clés ; tout s'exécute localement dans votre navigateur.
Rendez un mur de SQL lisible à nouveau. Collez une requête - une ligne ou mille - et elle se reformate pendant que vous tapez. Choisissez le dialecte afin que la syntaxe propre au dialecte ne soit pas abîmée, puis choisissez l'indentation et la casse des mots-clés utilisées par votre équipe.
La bibliothèque de formatage SQL n'a pas pu se charger. Veuillez recharger la page.
Mettre en forme du SQL que d'autres doivent lire
Pourquoi le sélecteur de dialecte compte
SQL est une norme à peu près comme l'orthographe anglaise est une norme. Chaque moteur implémente le cœur commun puis ajoute une syntaxe que personne d'autre n'a, et un formateur qui ne sait pas quel moteur vous vise analysera mal cette syntaxe ou la laissera passer sans formatage.
Les différences ne sont pas exotiques. Le seul délimiteur d'identifiants divise déjà le terrain : MySQL utilise les backticks, PostgreSQL et le SQL standard utilisent les guillemets doubles, et SQL Server utilise les crochets. Un formateur qui suppose la mauvaise convention peut traiter un identifiant quoté comme un littéral de chaîne et reformater la requête autour d'une frontière qui n'existe pas. Au-delà du délimiteur, il y a LIMIT contre TOP contre FETCH FIRST, l'opérateur de conversion :: de PostgreSQL, les variables T-SQL préfixées par @, les chemins de projet encapsulés dans des backticks de BigQuery et la clause QUALIFY de Snowflake. Choisir le bon dialecte est ce qui les conserve intacts.
L'indentation est une décision de diff
La largeur d'indentation et la casse des mots-clés paraissent cosmétiques, mais elles déterminent l'apparence de votre historique de gestion de versions. Le formatage n'est utile que s'il est cohérent, car dès que deux personnes formatent le même fichier différemment, chaque commit charrie une vague de modifications d'espaces blancs sans rapport et la revue de code cesse de fonctionner. Choisissez une configuration, inscrivez-la dans le dépôt, et appliquez-la mécaniquement.
Les mots-clés en majuscules sont la convention la plus courante et ils aident à la lecture d'une requête dense, car les mots structurels se détachent visuellement de vos noms de tables et de colonnes. Les minuscules ont gagné du terrain dans les bases de code qui traitent SQL comme du code ordinaire et n'aiment pas crier. Conserver est le bon choix quand vous formatez la requête de quelqu'un d'autre et voulez changer la mise en page sans toucher un seul caractère de son texte, ce qui rend le diff résultant purement structurel.
Tabulations contre espaces : l'argument habituel s'applique, avec un léger spécifique à SQL : les requêtes sont souvent collées dans des terminaux, des systèmes de tickets et des clients de chat qui rendent une tabulation sur huit colonnes. Une requête très imbriquée indentée avec des tabulations peut s'enrouler illisiblement exactement là où vous êtes le plus susceptible de la partager.
Ce qu'un formateur ne fera pas
Le formatage est purement présentatif. Il ne rendra pas une requête plus rapide, et il ne change rien au plan produit par l'optimiseur. Une sous-requête corrélée magnifiquement indentée s'exécute toujours une fois par ligne. Utilisez EXPLAIN pour la performance ; utilisez un formateur pour la lisibilité.
Il ne valide pas non plus. Cet outil analyse suffisamment pour reformater le texte, mais ce n'est pas l'analyseur du moteur et il formatera volontiers une requête avec une colonne mal orthographiée ou une condition de jointure manquante. Un format propre n'est pas une vérification de syntaxe, et la seule autorité sur la validité d'une requête est la base de données sur laquelle vous comptez l'exécuter.
La seule habitude à adopter avec le formatage est la paramétrisation. Formater une requête dont les valeurs sont concaténées dans la chaîne rend le risque d'injection plus lisible mais pas moins réel. Si vous vous retrouvez à formater du SQL contenant une saisie utilisateur injectée directement dans le texte, le formatage n'est pas le problème à corriger en premier.
FAQ
Quels dialectes SQL sont pris en charge ?
Quatorze : SQL standard, MySQL, MariaDB, PostgreSQL, SQLite, SQL Server T-SQL, Oracle PL/SQL, IBM Db2, BigQuery, Snowflake, Redshift, Hive, Spark SQL et Trino. Choisir le bon préserve une syntaxe propre au dialecte telle que le délimiteur d'identifiant et les opérateurs de conversion.
Le formatage change-t-il ce que fait ma requête ?
Non. Seuls les espaces blancs, les sauts de ligne et la casse des mots-clés changent, donc l'instruction est sémantiquement identique. Notez que la casse des mots-clés est sûre car les mots-clés SQL sont insensibles à la casse ; vos identifiants et littéraux de chaîne ne sont jamais re-casés.
Cela rendra-t-il ma requête plus rapide ?
Non. Le formatage est présentatif et l'optimiseur voit la même instruction quelle que soit la méthode. Pour la performance, lancez EXPLAIN ou EXPLAIN ANALYZE sur votre base de données réelle et examinez le plan.
Mon SQL est-il envoyé à un serveur ?
Non. sql-formatter s'exécute entièrement dans votre navigateur et rien n'est transmis. Cela compte ici car les vraies requêtes intègrent souvent des noms de tables, des détails de schéma et parfois des valeurs littérales de production.
Pourquoi ma requête échoue-t-elle au formatage ?
Généralement des guillemets ou parenthèses non équilibrés, ou une syntaxe propre au dialecte analysée avec le mauvais dialecte. Basculez d'abord le sélecteur de dialecte pour correspondre à votre base de données ; si cela échoue encore, cherchez un littéral de chaîne non fermé.
Dois-je utiliser des tabulations ou des espaces ?
L'un ou l'autre, tant que toute l'équipe utilise le même. Les espaces s'affichent identiquement partout, ce qui aide quand les requêtes sont collées dans des terminaux, des tickets ou des chats ; les tabulations permettent à chaque lecteur de choisir sa propre largeur dans un éditeur.