SQLNice

首页/博客/SQL 格式化最佳实践

SQL 格式化最佳实践:提升代码质量的 10 个技巧(2026)

2026-01-29
阅读时间: 6 分钟
最佳实践

良好的 SQL 代码格式化不仅仅是美观问题,更是关乎代码质量、团队协作和长期维护。本文总结了 10 个 SQL 格式化最佳实践,涵盖命名规范、缩进规则、注释标准等关键方面,帮助你写出更专业、更易维护的 SQL 代码。

无论你是数据库开发者、数据分析师还是 DBA,掌握这些最佳实践都能显著提升工作效率,减少 bug,让团队协作更顺畅。

1关键字统一大写

SQL 关键字(SELECT、FROM、WHERE 等)统一使用大写,可以让代码结构一目了然,与表名、列名等标识符形成明显对比。

❌ 不推荐:混用大小写

select name, email
from users
where status='active'

✅ 推荐:关键字大写

SELECT name, email
FROM users
WHERE status = 'active'

💡 提示

大多数团队采用"关键字大写,标识符小写"规范。如果团队有其他约定,保持一致即可。

2每个 SELECT 列独立一行

将 SELECT 子句中的每个列名放在单独一行,便于阅读、修改和代码审查。长查询中尤其重要。

❌ 不推荐:列名挤在一起

SELECT id, name, email, phone, address, city FROM users

✅ 推荐:每列独立一行

SELECT
    id,
    name,
    email,
    phone,
    address,
    city
FROM users

好处:容易添加/删除列,Git diff 更清晰,注释单个列也更方便。

3使用一致的缩进(2 或 4 空格)

选择 2 空格或 4 空格作为缩进标准,团队统一即可。避免混用 Tab 和空格。

SELECT
    u.name,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o
    ON u.id = o.user_id
WHERE u.status = 'active'
GROUP BY u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC

注意

子查询、JOIN 条件、WHERE 条件等都需要适当缩进,以反映逻辑层级。

4操作符两侧加空格

=>+ 等操作符两侧添加空格,提高可读性。

❌ 不推荐

WHERE age>18 AND score>=80

✅ 推荐

WHERE age > 18 AND score >= 80

5使用有意义的别名

表别名和列别名应当简洁且有意义,避免使用 t1col1 等无意义名称。

❌ 不推荐:无意义别名

SELECT
    t1.col1,
    t2.col2
FROM table1 t1
JOIN table2 t2
    ON t1.id = t2.fk

✅ 推荐:清晰的别名

SELECT
    u.name AS user_name,
    o.total AS order_total
FROM users u
JOIN orders o
    ON u.id = o.user_id

常见约定:users → u, orders → o, products → p。团队内保持一致即可。

6子查询合理缩进

子查询应当增加一层缩进,清晰反映层级关系。复杂嵌套时更为重要。

SELECT
    u.name,
    u.email,
    (
        SELECT COUNT(*)
        FROM orders o
        WHERE o.user_id = u.id
            AND o.status = 'completed'
    ) AS completed_orders
FROM users u
WHERE u.created_at > (
    SELECT MIN(created_at)
    FROM users
    WHERE region = 'CN'
)

💡 提示

使用 SQLNice 等工具可以自动识别并格式化子查询,节省时间。

7添加必要的注释

复杂逻辑、业务规则、临时解决方案等都应当添加注释说明。但避免过度注释显而易见的代码。

-- 获取活跃用户的订单统计
-- 活跃定义:30天内有登录记录
SELECT
    u.name,
    COUNT(o.id) AS order_count,
    SUM(o.total) AS total_amount
FROM users u
LEFT JOIN orders o
    ON u.id = o.user_id
    AND o.created_at > NOW() - INTERVAL 30 DAY  -- 仅统计近30天订单
WHERE u.last_login_at > NOW() - INTERVAL 30 DAY
GROUP BY u.name
HAVING order_count > 0  -- 排除没有订单的用户

注释规范:单行用 --,多行用 /* */

8避免 SELECT *

明确列出需要的列,而不是使用 SELECT *。这能提高性能、可读性和维护性。

❌ 不推荐:使用 SELECT *

SELECT * FROM users

问题:不知道会返回哪些列,表结构变化会导致意外结果,浪费带宽

✅ 推荐:明确指定列

SELECT id, name, email, created_at FROM users

好处:明确需求,便于优化,减少数据传输

9使用 CTE 代替复杂嵌套

对于复杂查询,使用 CTE(Common Table Expression,WITH 子句)可以让代码更清晰、更易维护。

❌ 复杂嵌套难以阅读

SELECT *
FROM (
  SELECT *
  FROM (
    SELECT ...
    FROM users
  ) t1
  WHERE ...
) t2
WHERE ...

✅ 使用 CTE 更清晰

WITH active_users AS (
    SELECT ...
    FROM users
    WHERE status = 'active'
),
user_orders AS (
    SELECT ...
    FROM orders
)
SELECT *
FROM active_users au
JOIN user_orders uo
    ON au.id = uo.user_id

10制定并遵守团队规范

以上 9 条是通用最佳实践,但最重要的是团队内部保持一致。建议:

  • 制定团队 SQL 编码规范文档,涵盖格式、命名、注释等
  • 使用自动化工具(如 SQLNice、SQL Formatter)强制执行格式
  • Code Review 中检查 SQL 代码质量
  • 集成到 CI/CD 流程,提交前自动格式化
  • 定期回顾和更新规范,保持与时俱进

🎯 团队规范示例

参考 SQL Style Guide 等开源规范,结合团队实际情况定制。

⚠️常见错误与解决方案

错误1:格式化后逻辑错误

原因:手动格式化时删除了必要的括号或逗号
解决:使用自动化工具(如 SQLNice),格式化后运行测试验证

错误2:团队成员格式不一致

原因:没有统一规范或强制执行
解决:建立规范文档,使用 Git Hook 或 CI 检查

错误3:过度格式化导致代码冗长

原因:简单查询也严格换行
解决:简单查询(3列以内)可以单行,复杂查询再严格格式化

📚总结

SQL 格式化最佳实践的核心是可读性、一致性和可维护性。本文介绍的 10 个技巧涵盖了格式化的各个方面:

1. 关键字大写 - 提高可读性
2. 每列独立一行 - 便于修改
3. 一致的缩进 - 反映层级
4. 操作符加空格 - 清晰易读
5. 有意义的别名 - 见名知意
6. 子查询缩进 - 结构清晰
7. 添加注释 - 解释逻辑
8. 避免 SELECT * - 明确需求
9. 使用 CTE - 简化嵌套
10. 团队规范 - 保持一致

记住:工具只是辅助,规范才是关键。使用 SQLNice 等自动化工具可以节省时间,但团队内部保持一致的编码习惯更为重要。

一键格式化你的 SQL 代码

SQLNice 支持所有最佳实践,智能识别子查询,免费使用

立即使用 SQLNice