可读的SQL不是可选的

你继承了一个查询。它是一行。400个字符。多个join、子查询和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;

join条件在哪里？过滤什么？每列来自哪个表？

现在想象凌晨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类型。单独的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

对于简单join，将join条件放在同一行。对于复杂条件，换到下一行。

性能怎么样？

格式化不影响执行。数据库优化器不在乎空白。

但格式化的SQL更容易优化。你可以看到结构，识别不必要的join，发现缺失的索引。

不可读的SQL隐藏性能问题。

团队标准

选择一种风格。记录它。用自动格式化工具强制执行。

存在不同的风格。有些团队把逗号放在行首。有些大写所有东西。有些不大写。

一致性比你选择哪种风格更重要。

---

每个查询被阅读的次数多于被编写的次数。为可读性格式化。你的队友——和未来的你——会感谢你。