SQL 格式化最佳实践:提升代码质量的 10 个技巧(2026)
良好的 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 >= 805使用有意义的别名
表别名和列别名应当简洁且有意义,避免使用 t1、col1 等无意义名称。
❌ 不推荐:无意义别名
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_id10制定并遵守团队规范
以上 9 条是通用最佳实践,但最重要的是团队内部保持一致。建议:
- 制定团队 SQL 编码规范文档,涵盖格式、命名、注释等
- 使用自动化工具(如 SQLNice、SQL Formatter)强制执行格式
- 在 Code Review 中检查 SQL 代码质量
- 集成到 CI/CD 流程,提交前自动格式化
- 定期回顾和更新规范,保持与时俱进
🎯 团队规范示例
参考 SQL Style Guide 等开源规范,结合团队实际情况定制。
⚠️常见错误与解决方案
错误1:格式化后逻辑错误
原因:手动格式化时删除了必要的括号或逗号
解决:使用自动化工具(如 SQLNice),格式化后运行测试验证
错误2:团队成员格式不一致
原因:没有统一规范或强制执行
解决:建立规范文档,使用 Git Hook 或 CI 检查
错误3:过度格式化导致代码冗长
原因:简单查询也严格换行
解决:简单查询(3列以内)可以单行,复杂查询再严格格式化
📚总结
SQL 格式化最佳实践的核心是可读性、一致性和可维护性。本文介绍的 10 个技巧涵盖了格式化的各个方面:
记住:工具只是辅助,规范才是关键。使用 SQLNice 等自动化工具可以节省时间,但团队内部保持一致的编码习惯更为重要。
一键格式化你的 SQL 代码
SQLNice 支持所有最佳实践,智能识别子查询,免费使用
立即使用 SQLNice