可讀的 SQL 不是可選的

你繼承了一個查詢。它是一行。400 個字符。多個連接、子查詢和 CASE 陳述式都擠在一起。

祝你理解它好運。

SQL 格式化不是關於美學。而是關於查詢是否可維護。

密集 SQL 的問題

SELECT u.id,u.name,o.total,p.name FROM users u JOIN orders o ON u.id=o.user_id JOIN products p ON o.product_id=p.id WHERE o.created_at>'2024-01-01' AND u.status='active' ORDER BY o.total DESC;

連接條件在哪裡?過濾什麼?每個欄位來自哪個表?

現在想像在凌晨 2 點除錯這個。

同一個查詢,可讀

SELECT
    u.id,
    u.name,
    o.total,
    p.name
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
WHERE o.created_at > '2024-01-01'
    AND u.status = 'active'
ORDER BY o.total DESC;

每個子句都有自己的行。條件對齊。結構是可見的。

有效的格式化規則

每個子句一行。 SELECT、FROM、WHERE、ORDER BY 各自有自己的行。

欄位在單獨的行上。 長 SELECT 清單變得可掃描。

縮排繼續條件。 多個 WHERE 條件對齊。

大寫關鍵字。 SELECT、FROM、WHERE 從表名和欄位中脫穎而出。

一致的大小寫。 選擇一種樣式。堅持它。

子查詢格式化

子查詢很快變得混亂。清楚地縮排它們:

SELECT *
FROM orders
WHERE user_id IN (
    SELECT id
    FROM users
    WHERE status = 'premium'
)

或者當子查詢變得複雜時使用 CTE:

WITH premium_users AS (
    SELECT id
    FROM users
    WHERE status = 'premium'
)
SELECT *
FROM orders
WHERE user_id IN (SELECT id FROM premium_users)

CTE 通常比巢狀子查詢更清楚。

JOIN 格式化

總是指定連接類型。單獨的 JOIN 是 INNER JOIN,但明確更好。

SELECT *
FROM orders o
INNER JOIN users u ON o.user_id = u.id
LEFT JOIN shipping s ON o.id = s.order_id

將連接條件放在同一行以進行簡單連接。對於複雜條件換到下一行。

效能呢?

格式化不影響執行。資料庫優化器不關心空白。

但格式化的 SQL 更容易優化。你可以看到結構,識別不必要的連接,發現缺失的索引。

無法閱讀的 SQL 隱藏效能問題。

團隊標準

選擇一種樣式。記錄它。使用自動格式化器強制執行。

存在不同的樣式。有些團隊將逗號放在行的開頭。有些將所有東西都大寫。有些不這樣做。

一致性比你選擇哪種樣式更重要。

---

每個查詢被讀取的次數比被寫入的次數多。為可讀性格式化。你的團隊成員——和你未來的自己——會感謝你。