SQL 格式化最佳實踐：打造乾淨的查詢語句

每位資料庫專業人員都曾接手過一段看起來像是有人把關鍵字隨意丟到牆上的查詢語句。良好的 SQL 格式化 能將難以閱讀的文字牆轉化為結構化、易於掃讀的程式碼，讓團隊中的任何人都能在幾秒內理解。無論你是在寫一段臨時的即席查詢，還是在建構一個將在正式環境中執行多年的預存程序，SQL 的格式化方式都至關重要。

你可以將任何雜亂的查詢貼到我們的 SQL 格式化工具中，立即獲得乾淨、縮排正確的輸出——但理解為什麼某些格式化選擇更好，將使你成為更優秀的 SQL 開發人員。

為什麼 SQL 格式化很重要

格式不佳的 SQL 會在整個工作流程中產生連鎖問題：

除錯時間增加三倍 — 當查詢回傳錯誤結果時，你需要用肉眼追蹤邏輯。雜亂的格式會隱藏邏輯錯誤。
程式碼審查停滯 — 審查者花時間在解讀結構上，而非評估邏輯。
合併衝突倍增 — 格式不一致意味著每位團隊成員的格式化方式不同，產生不必要的 git 差異。
新人上手困難 — 新團隊成員難以理解埋藏在糾結查詢中的業務邏輯。
正式環境事故擴大 — 在緊急情況下，沒人想去解開一個 200 行且毫無換行的查詢。

重點是：SQL 格式化不是為了美觀，而是為了降低認知負擔。一個格式良好的查詢，在你還沒讀到欄位名稱之前，就能傳達它的意圖。

關鍵字大小寫：選定一個慣例並堅持下去

SQL 格式化中最具爭議的話題就是關鍵字大小寫。有三種常見的做法：

大寫關鍵字（最常見）：

SELECT
    u.first_name,
    u.last_name,
    o.order_total
FROM users u
INNER JOIN orders o ON u.id = o.user_id
WHERE o.order_date >= '2025-01-01'
ORDER BY o.order_total DESC;

小寫關鍵字：

select
    u.first_name,
    u.last_name,
    o.order_total
from users u
inner join orders o on u.id = o.user_id
where o.order_date >= '2025-01-01'
order by o.order_total desc;

首字母大寫關鍵字：

Select
    u.first_name,
    u.last_name,
    o.order_total
From users u
Inner Join orders o On u.id = o.user_id
Where o.order_date >= '2025-01-01'
Order By o.order_total Desc;

大寫關鍵字仍然是業界標準，而且理由充分。它們在 SQL 關鍵字和你的表名/欄位名之間建立了即時的視覺區分。你的眼睛可以掃描左側邊緣，立即理解查詢結構：SELECT、FROM、WHERE、ORDER BY。

值得一提的是：無論你選擇哪種慣例，都應該用自動化工具來強制執行。我們的 SQL 格式化工具會自動處理關鍵字大小寫，讓你的整個團隊無需思考就能保持一致。

主要子句的縮排策略

良好的縮排是可讀 SQL 的基礎。每個主要子句應從左側邊緣開始，其內容則縮排一個層級。

SELECT 子句

將每個欄位放在獨立的一行。這使得新增、移除或註解欄位變得輕而易舉：

SELECT
    e.employee_id,
    e.first_name,
    e.last_name,
    e.department_id,
    d.department_name,
    e.hire_date,
    e.salary
FROM employees e
INNER JOIN departments d ON e.department_id = d.id;

避免這種常見的反模式：

-- 難以掃讀，難以修改
SELECT e.employee_id, e.first_name, e.last_name, e.department_id, d.department_name, e.hire_date, e.salary
FROM employees e INNER JOIN departments d ON e.department_id = d.id;

FROM 和 JOIN 子句

每個 JOIN 佔用獨立的一行。ON 條件跟隨其 JOIN，如果跨越多個條件則進一步縮排：

SELECT
    o.order_id,
    c.customer_name,
    p.product_name,
    oi.quantity,
    oi.unit_price
FROM orders o
INNER JOIN customers c
    ON o.customer_id = c.id
INNER JOIN order_items oi
    ON o.id = oi.order_id
LEFT JOIN products p
    ON oi.product_id = p.id
WHERE o.status = 'completed'
    AND o.order_date >= '2025-01-01';

WHERE 子句

每個條件佔用獨立的一行。將布林運算子（AND/OR）放在每行的開頭——這使得在除錯時註解掉個別條件變得非常簡單：

WHERE o.status = 'completed'
    AND o.order_date >= '2025-01-01'
    AND o.order_date < '2026-01-01'
    AND c.region IN ('US', 'CA', 'UK')
    -- AND o.total > 100  （暫時停用）

好消息是：一旦你內化了這個模式，你會更快地發現邏輯錯誤。每個條件都在視覺上被隔離開來，因此遺漏或不正確的篩選條件會立即跳出來。

格式化複雜的 JOIN

真實世界的查詢很少有簡單的單欄位 JOIN。以下是如何清晰地處理多條件 JOIN：

SELECT
    s.sale_id,
    s.sale_date,
    p.product_name,
    w.warehouse_name,
    i.quantity_on_hand
FROM sales s
INNER JOIN products p
    ON s.product_id = p.id
LEFT JOIN inventory i
    ON p.id = i.product_id
    AND i.warehouse_id = s.warehouse_id
    AND i.snapshot_date = s.sale_date
LEFT JOIN warehouses w
    ON i.warehouse_id = w.id
WHERE s.sale_date >= '2025-06-01';

注意額外的 JOIN 條件是如何縮排到與第一個 ON 條件相同的層級。這清楚地表明所有三個條件都屬於同一個 JOIN——而不是被意外放錯位置的 WHERE 子句。

對於自連接，使用有意義的別名而非神秘的單字母：

SELECT
    mgr.first_name AS manager_name,
    emp.first_name AS employee_name,
    emp.hire_date
FROM employees emp
INNER JOIN employees mgr
    ON emp.manager_id = mgr.employee_id
WHERE mgr.department_id = 10;

CTE 格式化（WITH 子句）

通用表運算式（CTE）值得特別注意格式化，因為它們可以決定複雜查詢的可讀性好壞。每個 CTE 都應被視為獨立的格式化區塊：

WITH monthly_revenue AS (
    SELECT
        DATE_TRUNC('month', order_date) AS revenue_month,
        SUM(order_total) AS total_revenue,
        COUNT(DISTINCT customer_id) AS unique_customers
    FROM orders
    WHERE order_date >= '2025-01-01'
    GROUP BY DATE_TRUNC('month', order_date)
),

customer_segments AS (
    SELECT
        customer_id,
        SUM(order_total) AS lifetime_value,
        CASE
            WHEN SUM(order_total) >= 10000 THEN 'platinum'
            WHEN SUM(order_total) >= 5000 THEN 'gold'
            WHEN SUM(order_total) >= 1000 THEN 'silver'
            ELSE 'bronze'
        END AS segment
    FROM orders
    GROUP BY customer_id
)

SELECT
    mr.revenue_month,
    mr.total_revenue,
    mr.unique_customers,
    COUNT(CASE WHEN cs.segment = 'platinum' THEN 1 END) AS platinum_count,
    COUNT(CASE WHEN cs.segment = 'gold' THEN 1 END) AS gold_count
FROM monthly_revenue mr
CROSS JOIN customer_segments cs
GROUP BY mr.revenue_month, mr.total_revenue, mr.unique_customers
ORDER BY mr.revenue_month;

CTE 格式化的關鍵規則：

在每個結束括號和逗號後用空行分隔 CTE
CTE 主體的縮排 應與任何一般查詢相同
使用描述性的 CTE 名稱 — monthly_revenue 永遠勝過 cte1
最終的 SELECT 應與 WITH 關鍵字保持相同的縮排層級

子查詢格式化

子查詢應比外層查詢多縮排一個層級。使用括號作為視覺邊界：

SELECT
    d.department_name,
    d.budget,
    dept_stats.avg_salary,
    dept_stats.employee_count
FROM departments d
INNER JOIN (
    SELECT
        department_id,
        AVG(salary) AS avg_salary,
        COUNT(*) AS employee_count
    FROM employees
    WHERE status = 'active'
    GROUP BY department_id
    HAVING COUNT(*) >= 5
) dept_stats
    ON d.id = dept_stats.department_id
WHERE d.budget > 100000
ORDER BY dept_stats.avg_salary DESC;

當你的巢狀子查詢深達三四層時，通常這就是重構為 CTE 的信號。CTE 能將巢狀結構扁平化，並為每個邏輯步驟提供可讀的名稱。我們的 SQL 格式化工具可以幫助你識別可能受益於重構的深層巢狀結構。

CASE 陳述式格式化

CASE 陳述式無處不在——在 SELECT 列表、WHERE 子句、ORDER BY，甚至 JOIN 條件中都會出現。透過一致的縮排保持可讀性：

SELECT
    order_id,
    order_total,
    CASE
        WHEN order_total >= 1000 THEN 'high-value'
        WHEN order_total >= 100 THEN 'medium-value'
        ELSE 'low-value'
    END AS order_tier,
    CASE status
        WHEN 'shipped' THEN 'In Transit'
        WHEN 'delivered' THEN 'Complete'
        WHEN 'returned' THEN 'Refund Pending'
        ELSE 'Processing'
    END AS display_status
FROM orders;

WHEN 和 ELSE 關鍵字彼此對齊，END 關鍵字與 CASE 對齊。這創造了一個乾淨的視覺區塊，便於掃讀和修改。

SQL 中的註解最佳實踐

SQL 註解是你未來自己最好的朋友。請策略性地使用它們：

區塊註解用於說明查詢目的：

/*
 * 月營收報表
 * 按產品類別生成營收明細
 * 使用者：財務儀表板（Tableau）
 * 最後修改日期：2025-06-15
 */
SELECT
    pc.category_name,
    SUM(oi.quantity * oi.unit_price) AS revenue
FROM order_items oi
INNER JOIN products p ON oi.product_id = p.id
INNER JOIN product_categories pc ON p.category_id = pc.id
GROUP BY pc.category_name;

行內註解用於說明非顯而易見的邏輯：

WHERE o.order_date >= '2025-01-01'
    AND o.status != 'cancelled'
    AND o.payment_verified = TRUE    -- 排除待付款審核
    AND c.account_type != 'internal' -- 員工測試訂單使用內部帳戶

段落註解用於長查詢：

-- === 營收計算 ===
...
-- === 客戶篩選 ===
...
-- === 最終彙總 ===

避免過度註解顯而易見的內容。在 SELECT 語句上方加上 -- 選取所有欄位 只會增加噪音，而非清晰度。

不同 SQL 方言的格式化

SQL 方言有各自的語法特點，但格式化原則保持一致。以下是各方言的特定考量：

MySQL

SELECT
    product_name,
    price,
    IFNULL(discount, 0) AS discount,
    price - IFNULL(discount, 0) AS final_price
FROM products
WHERE category_id IN (1, 3, 5)
LIMIT 50 OFFSET 100;

PostgreSQL

SELECT
    product_name,
    price,
    COALESCE(discount, 0) AS discount,
    price - COALESCE(discount, 0) AS final_price
FROM products
WHERE category_id = ANY(ARRAY[1, 3, 5])
LIMIT 50 OFFSET 100;

SQL Server

SELECT TOP 50
    product_name,
    price,
    ISNULL(discount, 0) AS discount,
    price - ISNULL(discount, 0) AS final_price
FROM products
WHERE category_id IN (1, 3, 5)
ORDER BY price DESC
OFFSET 100 ROWS FETCH NEXT 50 ROWS ONLY;

無論使用哪種方言，結構化格式保持不變：關鍵字獨佔一行、一致的縮排、每行一個欄位。alltools.one 上的 SQL 格式化工具支援所有主要方言，無論你使用哪種資料庫，都能獲得一致的結果。

自動格式化 vs. 手動格式化

手動格式化適用於短查詢。但當你的團隊超過兩人時，就需要自動化的強制執行。原因如下：

自動格式化的好處：

零爭論 — 格式化工具決定，大家遵循
一致的 git 差異 — 不再有僅空白字元變更的提交混雜在 Pull Request 中
速度 — 手動重新格式化一個 500 行的預存程序需要幾分鐘。工具在毫秒內完成。
新人培訓 — 新團隊成員無需記住風格指南

手動格式化仍有優勢的場景：

特定欄位的對齊，例如 INSERT 語句或複雜的 CASE 區塊
保留刻意的格式化，用於文件說明用的查詢
邊緣情況，當自動化工具反而降低可讀性時（罕見，但確實會發生）

務實的做法：以自動格式化作為基準，然後手動微調少數需要特別處理的查詢。先用我們的 SQL 格式化工具處理你的 SQL，再根據需要調整特定段落。

快速參考：SQL 格式化檢查清單

在將任何 SQL 提交到程式碼庫之前，請逐一確認以下清單：

關鍵字大小寫一致（建議使用大寫）
每個主要子句（SELECT、FROM、WHERE、GROUP BY、ORDER BY）從新行開始
SELECT 中的欄位每行一個
每個 JOIN 獨佔一行，ON 條件適當縮排
WHERE 條件每行一個，AND/OR 放在行首
CTE 使用描述性名稱並保持一致的縮排
CASE 陳述式的 WHEN/ELSE 對齊
註解說明的是「為什麼」，而非「是什麼」
表格別名有意義（複雜查詢中不要只用單字母）
超過兩層的巢狀子查詢已重構為 CTE