SQL 格式化教程：让你的查询更易读 – wiki基地

---

SQL 格式化教程：让你的查询更易读

SQL（结构化查询语言）是与数据库交互的核心工具。无论是进行数据查询、修改还是定义数据库结构，SQL 都无处不在。对于许多开发者、数据分析师和数据库管理员来说，编写和阅读 SQL 查询是日常工作的重要组成部分。然而，一个常见的问题是：写出来的 SQL 代码往往杂乱无章，难以理解。

想象一下，你正在调试一个复杂的存储过程，里面包含了数十行甚至上百行的 SQL 代码，它们挤在几行里，没有缩进，没有换行，大小写混乱。这就像在黑暗中摸索，效率低下，错误百出。

这就是 SQL 格式化的重要性所在。格式化不仅仅是为了美观，更是为了提升代码的可读性、可维护性和团队协作效率。一个良好格式化的 SQL 查询，能够让你和你的同事更快地理解代码意图，更容易地发现逻辑错误，减少调试时间，最终提高开发效率。

本教程将详细介绍 SQL 格式化的基本原则、常用约定和一些进阶技巧，帮助你写出清晰、易读的 SQL 代码。

为什么需要格式化 SQL？

在深入探讨如何格式化之前，我们先来明确为什么这件事如此重要：

1. 提升可读性： 这是最直接的好处。整洁的代码结构使逻辑流程一目了然。关键字、表名、列名、条件、连接关系等元素各司其职，互不干扰。
2. 加速理解： 当你需要阅读别人写的或者自己很久以前写的 SQL 时，良好的格式能让你迅速抓住重点，理解查询的业务逻辑和数据流向。
3. 简化调试： 格式化后的代码更容易定位问题。当查询返回不正确的结果时，你可以沿着清晰的结构快速检查 SELECT 列表、FROM 子句、JOIN 条件、WHERE 过滤、GROUP BY 分组等环节。
4. 降低错误率： 混乱的代码更容易导致低级错误，例如括号不匹配、条件遗漏、连接错误等。清晰的结构能帮助你避免这些陷阱。
5. 增强可维护性： 当你需要修改或扩展现有查询时，格式良好的代码更容易进行修改，不易引入新的错误。
6. 促进团队协作： 统一的格式规范使得团队成员之间的代码更容易相互理解和评审。大家遵循相同的“语言习惯”，沟通成本大大降低。
7. 代码即文档： 有时候，良好的格式化和适当的注释本身就是一种有效的文档，解释了代码的结构和意图。

简而言之，花时间格式化 SQL，就像整理你的工作空间一样，前期投入一点精力，换来的是长期的效率提升和麻烦减少。

SQL 格式化的核心原则

虽然不同的团队或个人可能有细微的格式偏好，但以下几个核心原则是普遍遵循的，它们构成了 SQL 格式化的基石：

1. 一致性（Consistency）： 这是最重要的原则。无论你选择哪种格式风格，请务必在整个项目、整个团队中保持一致。如果团队已经有约定，请严格遵守。
2. 分段与换行（Segmentation & Line Breaks）： 将 SQL 查询的不同子句（SELECT, FROM, WHERE, GROUP BY, ORDER BY, JOIN 等）放在不同的行上，甚至缩进不同的层次，以区分它们的逻辑作用范围。
3. 缩进（Indentation）： 使用缩进展示代码的层级关系和结构。子句内部的元素（如列名、条件）相对于其父子句进行缩进。
4. 大小写规范（Case Sensitivity）： 对关键字、表名、列名等采用一致的大小写风格。虽然许多数据库系统对标识符不区分大小写（或默认不区分），但在代码中保持一致的大小写可以显著提高可读性。
5. 空格与标点（Spacing & Punctuation）： 在操作符、逗号、括号等周围使用一致的空格，使代码看起来更整洁，易于扫描。

接下来，我们将针对这些原则进行更详细的讲解，并提供具体的示例。

具体的格式化约定与实践

1. 大小写规范 (Case Convention)

约定：

• SQL 关键字使用大写： SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, AND, OR, AS, ON, IN, LIKE, COUNT, SUM 等。这样它们在代码中非常醒目，一眼就能识别出 SQL 的骨架。
• 表名和列名使用小写或特定风格： 表名和列名属于用户定义的标识符。常见的风格有：
  • 全小写 + 下划线 (snake_case)： user_accounts, first_name, order_date (这是许多数据库社区推荐的风格，因为它在多数数据库系统中兼容性最好，且在小写下易读)。
  • 小写 + 驼峰 (camelCase)： userAccounts, firstName, orderDate (在某些编程语言社区常见，但与 SQL 关键字的大写对比不强烈)。
  • 帕斯卡命名 (PascalCase)： UserAccounts, FirstName (常用于对象名或类型名)。
  • 保持与数据库定义一致： 如果数据库中的表名列名就是特定的风格，那么在查询中也保持一致。

示例：

“`sql
— 不推荐：大小写混乱，关键字不突出
select username, age from users where age > 18 order by username;

— 推荐：关键字大写，标识符小写+下划线
SELECT user_name, age
FROM users
WHERE age > 18
ORDER BY user_name;
“`

2. 分段与换行 (Segmentation & Line Breaks)

约定：

• 每个主要子句（SELECT, FROM, WHERE, GROUP BY, ORDER BY, LIMIT/FETCH FIRST）单独占一行。
• 每个 JOIN 子句单独占一行。
• 如果 SELECT 子句包含多个列，可以将每个列单独放在一行，特别是当列数量较多或包含复杂表达式时。 这使得查看和修改查询返回的列变得非常容易。
• 如果 WHERE 子句包含多个条件，可以将每个条件与 AND 或 OR 一起单独放在一行。
• ON 子句或复杂的表达式可以在父子句下方进行进一步换行和缩进。

示例：

“`sql
— 不推荐：所有内容挤在一行
SELECT u.user_id, u.user_name, p.product_name, oi.quantity, oi.price FROM users u JOIN orders o ON u.user_id = o.user_id JOIN order_items oi ON o.order_id = oi.order_id JOIN products p ON oi.product_id = p.product_id WHERE o.order_date >= ‘2023-01-01’ AND oi.quantity > 5 ORDER BY u.user_name, o.order_date;

— 推荐：按子句和元素换行
SELECT
u.user_id,
u.user_name,
p.product_name,
oi.quantity,
oi.price
FROM
users u
JOIN
orders o ON u.user_id = o.user_id — JOIN 子句单独一行，ON 条件在其下方或右侧
JOIN
order_items oi ON o.order_id = oi.order_id
JOIN
products p ON oi.product_id = p.product_id
WHERE
o.order_date >= ‘2023-01-01’
AND oi.quantity > 5 — 每个条件与逻辑运算符AND/OR一起单独一行
ORDER BY
u.user_name, — 如果ORDER BY/GROUP BY的列多，也可以每个占一行
o.order_date;
“`

3. 缩进 (Indentation)

约定：

• 使用一致的缩进单位： 通常使用 4 个空格或 2 个空格，或者使用 Tab 键（但需要注意 Tab 在不同编辑器中的宽度差异，推荐使用空格）。关键是保持一致。
• 子句内容相对于其父子句进行缩进： 例如，SELECT 列表中的列相对于 SELECT 关键字进行缩进；WHERE 子句中的条件相对于 WHERE 关键字进行缩进；ON 子句相对于 JOIN 关键字进行缩进。
• 嵌套结构（如子查询、CTE）应体现更深的缩进层次。

示例（结合换行）：

sql
-- 推荐：使用缩进展示结构
SELECT
c.customer_name,
COUNT(o.order_id) AS total_orders,
SUM(o.total_amount) AS total_spent
FROM
customers c
JOIN
orders o ON c.customer_id = o.customer_id -- ON 子句相对于 JOIN 缩进
WHERE
o.order_date BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY
c.customer_name -- GROUP BY 的列列表也可以缩进
HAVING
COUNT(o.order_id) > 10 -- HAVING 条件也可以缩进
ORDER BY
total_spent DESC;

4. 空格与标点 (Spacing & Punctuation)

约定：

• 在操作符（如 =, >, <, >=, <=, <>, !=, +, -, *, /）两侧添加空格。
• 在逗号（,）后面添加一个空格。
• 在括号 () 内部紧邻内容不加空格，外部需要时加空格（如函数调用 COUNT(column)，关键字后 IN (...)）。
• 在关键字和标识符之间添加空格。

示例：

“`sql
— 不推荐：空格混乱
SELECTname,ageFROMusersWHEREage>18;
SELECT name,age FROM users WHERE age > 18 ;

— 推荐：规范使用空格
SELECT name, age — 逗号后有空格
FROM users
WHERE age > 18; — 操作符两侧有空格
“`

5. 别名 (Aliases)

约定：

• 为表和复杂的列表达式使用别名（AS 关键字可以省略，但推荐使用以明确意图）。
• 选择有意义的别名，避免使用单个字母（除非是简单的 JOIN，如 u for users），尽量使用能表达表或列含义的缩写。
• 在 SELECT 列表中，如果列使用了别名，可以将别名与原列名/表达式对齐，以增强可读性（可选，但对齐效果很好）。

示例：

“`sql
— 不推荐：没有别名或别名不清晰/不对齐
SELECT
users.user_id,
orders.order_date,
SUM(order_items.price * order_items.quantity) total — 别名不对齐
FROM
users, orders, order_items — 老式JOIN语法不易读
WHERE
users.user_id = orders.user_id
AND orders.order_id = order_items.order_id;

— 推荐：使用有意义的别名并对齐
SELECT
u.user_id, — u 是 users 的别名
o.order_date, — o 是 orders 的别名
SUM(oi.price * oi.quantity) AS total_item_amount — oi 是 order_items 的别名，别名与表达式对齐
FROM
users AS u — 使用 AS 使别名更明确
JOIN
orders AS o ON u.user_id = o.user_id
JOIN
order_items AS oi ON o.order_id = oi.order_id;
“`

6. 注释 (Comments)

约定：

• 使用注释解释复杂逻辑、非常规做法或重要的业务规则。
• 单行注释使用 -- 开头。
• 多行注释使用 /* */ 包围。
• 避免过度注释，清晰的代码本身就是最好的文档。 注释应补充代码无法直观表达的信息，而不是重复代码本身。

示例：

“`sql
SELECT
p.product_name,
COUNT(oi.order_item_id) AS total_sold_items, — 计算该产品的总销售件数
SUM(oi.quantity * oi.price) AS total_revenue
FROM
products AS p
JOIN
order_items AS oi ON p.product_id = oi.product_id
WHERE
— 只统计2023年度的销售数据
EXISTS (
SELECT 1
FROM orders o
WHERE o.order_id = oi.order_id
AND o.order_date BETWEEN ‘2023-01-01’ AND ‘2023-12-31’
)
GROUP BY
p.product_name
ORDER BY
total_revenue DESC;

/
这个查询用于统计2023年各产品的销售总收入和销售件数。
JOIN order_items 和 products 表，然后通过 EXISTS 子查询过滤出2023年的订单项。
最后按产品名分组并计算总收入和总件数。
/
“`

7. 子查询与 CTEs (Subqueries & Common Table Expressions)

约定：

• 子查询通常需要额外的缩进，使其与外部查询区分开来。 如果子查询用于 FROM 子句（派生表），它应该像普通表一样处理，但其内部内容需要缩进。
• 公用表表达式 (CTEs)，使用 WITH 子句定义，其结构天然就比子查询清晰。 每个 CTE 应独立定义，并在其内部进行适当的格式化。主查询在使用 CTEs 时，也应遵循常规的格式化规则。

示例：

“`sql
— 子查询示例
SELECT
user_name,
total_spent
FROM
( — 子查询开始，内部缩进
SELECT
u.user_name,
SUM(o.total_amount) AS total_spent
FROM
users u
JOIN
orders o ON u.user_id = o.user_id
GROUP BY
u.user_name
) AS user_spending — 子查询作为派生表需要别名
WHERE
total_spent > 1000 — 外部查询继续正常格式化
ORDER BY
total_spent DESC;

— CTE 示例 (推荐用于提高复杂查询的可读性)
WITH UserTotalSpending AS ( — CTE 定义开始
SELECT
u.user_id,
u.user_name,
SUM(o.total_amount) AS total_spent
FROM
users u
JOIN
orders o ON u.user_id = o.user_id
GROUP BY
u.user_name
),
HighSpendingUsers AS ( — 另一个 CTE
SELECT
user_name,
total_spent
FROM
UserTotalSpending
WHERE
total_spent > 1000
) — CTEs 定义结束

— 主查询开始
SELECT
user_name,
total_spent
FROM
HighSpendingUsers — 使用 CTE
ORDER BY
total_spent DESC;
“`
CTE 的方式明显比子查询更容易理解其分步逻辑。

8. 其他子句的格式化

• CASE 表达式： 如果 CASE 表达式比较复杂，可以将 WHEN, THEN, ELSE, END 放在不同的行并缩进。
• INSERT, UPDATE, DELETE 语句： 这些语句也应遵循类似的原则。INSERT 的 VALUES 列表、UPDATE 的 SET 子句、DELETE 的 WHERE 子句都应该清晰地格式化。

示例：CASE 表达式

sql
SELECT
product_name,
price,
CASE -- CASE 关键字开始
WHEN price < 100 THEN 'Cheap' -- WHEN/THEN 子句缩进
WHEN price BETWEEN 100 AND 500 THEN 'Medium'
WHEN price > 500 THEN 'Expensive'
ELSE 'Unknown' -- ELSE 子句缩进
END AS price_category -- END 关键字，别名
FROM
products
ORDER BY
price;

利用工具自动化格式化

手动格式化固然重要，但依赖人工容易出错且效率低下。幸运的是，有许多工具可以帮助我们自动化 SQL 格式化过程，并强制执行一致的风格：

1. 数据库客户端/IDE 内置格式化功能： 大多数现代数据库客户端（如 DBeaver, SQL Developer, pgAdmin, MySQL Workbench）和通用 IDE（如 VS Code, IntelliJ IDEA）都内置了 SQL 格式化功能。通常只需选中代码，右键选择 “Format” 或使用快捷键即可。这些工具通常允许配置格式化规则。
2. 在线 SQL 格式化器： 许多网站提供在线 SQL 格式化服务。粘贴代码，选择风格，即可生成格式化后的代码。例如：SQL Formatter (这是一个通用的例子，具体网站可能需要搜索)。
3. 命令行工具： 一些工具可以在命令行中格式化 SQL 文件，方便集成到 CI/CD 流程中进行代码风格检查。例如 sqlfmt。
4. 编辑器插件/扩展： 对于 VS Code, Sublime Text 等编辑器，有大量的插件可用于 SQL 格式化。

建议：

• 利用好你日常使用的工具的格式化功能。
• 团队应约定使用同一种工具或配置，以确保格式的一致性。
• 在代码提交前，考虑运行格式化工具检查。

建立并遵守团队规范

如果是在团队环境中工作，建立一套统一的 SQL 格式化规范并让所有成员遵守至关重要。这可以写成一份简短的文档，包含本文提及的主要原则和约定，并强调一致性。定期的代码评审也可以作为检查和推行规范的机会。

总结

SQL 格式化并非可有可无的点缀，它是编写高质量、易于维护和协作的代码的重要组成部分。通过遵循以下核心原则：

• 一致性
• 分段与换行
• 缩进
• 大小写规范
• 空格与标点

并辅以有意义的别名、恰当的注释、以及清晰的子查询/CTE格式化，你可以显著提高 SQL 查询的可读性。

投入时间学习和实践 SQL 格式化，并积极利用自动化工具，不仅能让你的代码看起来更专业，更能实实在在地提升你的开发效率和团队的协作体验。从现在开始，写下一行 SQL 时，就考虑如何让它更易读吧！