SQL には、人間にとって読みやすいレイアウトと、マシンにとってコンパクトなワンライナーという 2 つの便利な形式があります。書式設定 (整形) では、キーワード、結合、およびネストされた選択を明確な行に配置して、レビュー担当者がロジックを理解できるようにします。縮小するとコメントと余分な空白が削除されるため、クエリのログ行またはデバッグ ダンプのバイト数が減ります。どちらもクエリを理解する代わりにはなりません。読み取りや保存の難しさが変わるだけです。 SQL Minifier & Formatter の同じステートメントで両方を試してください。ブラウザ内で実行され、アップロードはされません。
クイック回答
コードレビュー、PR の差分、および教育用の形式。ログ、メトリクス ラベル、または貼り付けられたデバッグ文字列の単一行ペイロードが必要な場合は、縮小してください。移行またはアプリのソースで配布するコピーを縮小しないでください。読み取り可能な状態にしておいてください。運用 SQL を保存するサーバーよりもクライアント側のツールを優先します。
レビューの可読性とログのペイロード サイズ
1 行の複数結合クエリは、プル リクエストの責任となります。インデントと改行により、「JOIN」、「WHERE」、およびサブクエリがアウトラインのようにスキャンされます。それが書式設定の仕事です。次の人 (将来のあなたを含む) が述語を微調整する前に意図を理解できるようにするのです。
- 聴衆が人間である場合のフォーマット - レビュー、ペアプログラミング、インシデントの記録、オンボーディングドキュメント。
- オーディエンスがパイプである場合、つまりサイズバジェットを含む構造化されたログ、チケットフィールドに貼り付けられたクリップボード、またはコンパクトな再生文字列の場合に縮小します。
- ソースの移行と ORM の生の SQL をフォーマットしたままにします。運用ツールに配置した使い捨てコピーのみを縮小します。
- 書式設定されたクエリと縮小されたクエリは意味的には同じステートメントである必要があり、空白とコメントのみが異なります。
JS や CSS と比べて SQL の縮小がまれな理由
フロントエンド アセットはページが読み込まれるたびにネットワーク上を移動するため、チームはデフォルトで JavaScript と CSS を縮小します。 SQL は通常、そうではありません。クエリはアプリまたはデータベースの隣に存在します。ボトルネックは計画と I/O であり、テキスト内のいくつかのスペースではありません。バンドラーと CDN があなたの「SELECT」を認識することはありません。
- JS/CSS minify は、ユーザーがダウンロードするバイト数を縮小します。 SQL minify によってクエリ時間が変更されることはほとんどありません。
- JSON API はワイヤ サイズを考慮して縮小されることがよくあります - JSON Minifier & Formatter を参照してください - SQL はリポジトリ内で適切なままです。
- SQL が縮小される場合、通常はログの健全性または 1 回限りのペーストのためであり、ビルド パイプラインのためではありません。
- ORM がすでにワンライナーをパラメータ化し、ログに記録している場合は、別の minify ステップがまったく必要ない可能性があります。
方言の落とし穴
「SQL」は 1 つの文法ではなく、ファミリーです。 PostgreSQL が MySQL バッククォート、SQL Server 括弧、または Oracle 固有の句を破壊できることを前提としたフォーマッタ。コメントと思われるものを削除するミニファイアーは、方言固有のヒントを破壊する可能性があります。
- 識別子: 二重引用符、バックティック、角括弧 - ブラインドで再フォーマットすると、エンジン間で意味が変わる可能性があります。
- コメント: `--` 行のコメントには改行が必要です。慎重に剥がすか、次のキーワードをコメントに貼り付けてください。
- ベンダーヒントと独自の関数 (`LIMIT`/`OFFSET` と `TOP`、`ILIKE`、`RETURNING`) - 実際に実行する方言を保持します。
- 文字列リテラルとドル引用符: 文字列内の単純な空白の崩壊はバグであり、機能ではありません。
同じステートメント、異なるエンジン
データベース間でクエリを移動する場合は、まず読みやすいように書式設定してから、方言のキーワードを手動で修正します。 Postgres SQL を MySQL 上で有効にするために自動フォーマットだけを信頼しないでください。
本番クエリをサーバー側のフォーマッタに貼り付けないでください
運用 SQL では、スキーマ名、テーブル構造、フィルター値、そして場合によってはリテラルに漏れた PII が埋め込まれることがよくあります。サーバー上でクエリをフォーマットするためにクエリをアップロードする Web サイトは、後でログ、サポート チケット、侵害など、ユーザーが制御できないコピーを作成します。
- テキストをデバイス外に送信しないブラウザ内ツールを推奨します。
- チームメイトとであってもクエリを共有する前に、リテラルとシークレットを編集してください。
- 「無料のオンライン SQL フォーマッタ」を他のペーストビンと同様に扱います。そうでないことが証明されるまで保持されるものとします。
- このサイトの SQL Minifier & Formatter は、プライベートなクライアント側での使用、つまりアップロードせずにフォーマットまたは縮小するために構築されています。
短い意思決定ガイド
- PR を開始しますか?形式。
- 文字数制限のあるログフィールドにクエリを詰め込みますか?縮小します。
- minify でコメントや文字列が壊れていないことを確認しますか?もう一度フォーマットして、精神的に差分を確認します。
- まだ SQL を学習していますか?フォーマットを維持する - 縮小された SQL はひどいチュートリアルです。
よくある質問
書式設定により、データベースによるクエリの実行方法が変わりますか?
いいえ。文字列リテラルの外側にある空白やコメントによって計画は変更されません。セマンティクスは、インデントではなく、キーワード、識別子、述語から得られます。
アプリケーションソース内の SQL を縮小する必要がありますか?
ほとんどありません。移行とチェックインされたクエリを読み取り可能な状態に保ちます。ログまたはペースト用に使い捨てのコピーのみを縮小します。
SQL の縮小化は JavaScript の縮小化と似ていますか?
どちらも不必要な空白を削除するという意味でのみ。 JS minify は、ローカルの名前を変更し、サイズの構文を書き換えることもよくあります。 SQL minify は、空白とコメントのみという控えめなままにする必要があります。そうしないと、方言が壊れる危険があります。
SQL の次に JSON と API ペイロードはどうでしょうか?
ワイヤー形式でも、ネットワーク パス上での minify のメリットが得られます。デバッグ時に JSON をフォーマットし、出荷時に最小化します。この記事で説明しているのと同じ分割が SQL に適用され、JSON Minifier & Formatter が適用されます。
ToolsMinify で安全にフォーマットおよび縮小できますか?
はい。 SQL Minifier & Formatter に貼り付け、format または minify を選択し、結果をコピーします。処理はブラウザ内に留まります。
ToolsMinify で試してみる
以下のすべてのツールはブラウザで実行できます - 無料、サインアップなし、何もアップロードされません。
- SQL ミニファイアーとフォーマッタ - SQL をデバイス上でプライベートに整形または縮小します。
- JSON ミニファイアーとフォーマッタ - API ペイロードの同じ形式と縮小のアイデア。
- JavaScript ミニファイアー - ここで、バイトがネットワークに到達するため、minify はルーチンです。
- すべての開発者ツール - 完全なカテゴリインデックス。
無料でお試しください
SQL Minifier & Formatter を開き、乱雑な結合を貼り付け、レビュー用にフォーマットし、ログ行のコピーを縮小します。これらすべてをブラウザーから離れることなく実行できます。