SQL 格式化

方言選擇器為什麼重要

SQL 之所以稱為標準，大致相當於英語拼寫稱為標準。每個引擎都實現公共核心，然後各自新增別家沒有的語法；如果格式化器不知道你的目標引擎，它要麼會誤解這些語法，要麼就靜默地原樣跳過不做處理。

這些差異並不冷僻。僅識別符號引用方式就已經分家：MySQL 用反引號，PostgreSQL 和標準 SQL 用雙引號，SQL Server 用方括號。假設了錯誤約定的格式化器，可能把帶引號的識別符號當成字串字面量，並圍繞一個根本不存在的邊界重新折行。除引用方式外，還有 LIMIT 與 TOP 與 FETCH FIRST 之別、PostgreSQL 的 :: 轉換運算子、T-SQL 中以 @ 開頭的變數、BigQuery 用反引號包裹的專案路徑，以及 Snowflake 的 QUALIFY 子句。選對方言，才能讓這些保持完整。

縮排其實是一個 diff 決策

縮排寬度和關鍵字大小寫看似只是外觀，實際上決定了你的版本歷史長什麼樣。格式化只有在保持一致時才有價值——一旦兩個人對同一個檔案用了不同的格式，每次提交都會夾帶一片無關的空白改動，程式碼評審就此失效。選定一套配置，寫進倉庫，然後機械地執行。

關鍵字全大寫是最常見的約定，在閱讀密集查詢時很有幫助，因為結構性詞彙能與表名列名在視覺上分開。近年在把 SQL 當作普通程式碼、不喜歡"喊話"風格的程式碼庫裡，全小寫也逐漸流行。而當你要格式化別人的查詢、希望只調整排版而不改動其一個字元時，"保持原樣"是正確選擇——這樣產生的 diff 是純結構性的。

製表符與空格之爭照舊，但 SQL 場景有個特有的細節：查詢經常被粘進終端、工單系統和聊天工具，而這些地方常把製表符渲染成八列寬。用製表符縮排的深層巢狀查詢，恰恰會在你最可能分享它的場合折行成一團亂麻。

格式化不會做的事

格式化純粹是呈現層面的。它不會讓查詢變快，也不會改變最佳化器生成的執行計劃。一個縮排優美的關聯子查詢，仍然是每行執行一次。效能問題請用 EXPLAIN，格式化只負責可讀性。

它同樣不做校驗。本工具的解析足以重排文本，但它不是資料庫引擎的解析器，一條列名拼錯或缺少連線條件的查詢，它照樣會格式化得漂漂亮亮。排版整潔不等於語法正確，唯一有權判定查詢是否有效的，是你打算執行它的那個資料庫。

有一個值得與格式化一起養成的習慣是引數化。把值直接拼進字串的查詢，格式化之後只是讓注入風險變得更易讀，風險本身分毫未減。如果你發現自己正在格式化一段把使用者輸入直接拼接進文本的 SQL，那麼首先需要修的顯然不是格式。