SQL书写规范是提升代码质量和团队效率的关键。很多开发者在实际工作中往往只关心查询能否正常运行，却忽视了代码的可读性与可维护性。经验表明，遵循统一格式的SQL语句，尤其是在团队协作或长期维护的场景下，能显著减少调试、排错和交接的时间成本。
SELECT 字段与关键字的对齐规范：如何避免混乱？
首先，SELECT 后的字段应逐行列出，首行缩进4个空格，后续字段左对齐。逗号统一放在字段行的前面，而非末尾——这一做法的好处是：删除或注释某字段时无需额外处理逗号，也不会因遗漏逗号导致语法错误。许多开发者习惯于将所有字段挤在一行，或将逗号置于行尾，导致后续修改时手忙脚乱。例如，写法 SELECT id, name, email FROM users 虽然简洁，但若需添加新字段或注释某列，极易出错。而下面这种写法则更加稳健：
SELECT id, name, emailFROM users
另外要注意：字段名前不要省略表别名。虽然在单表查询中可以正常运行，但一旦涉及 JOIN，就可能引发歧义或报错。因此，应从一开始就养成习惯，写成 users.id 或带别名的 u.id。
WHERE 与 JOIN 子句的缩进层级规范
WHERE、FROM、JOIN、ORDER BY 等子句必须单独成行，并与 SELECT 保持左对齐（即顶格或统一不缩进）。子句内部的逻辑条件或连接条件，应统一缩进4个空格。一个常见的错误是将 AND 或 ON 放在行尾，导致逻辑断裂，后续新增条件时也容易出错。正确的做法是将逻辑操作符置于条件块的左侧并顶格对齐：
SELECT u.id, u.nameFROM users AS uJOIN orders AS o ON u.id = o.user_idWHERE u.status = 'active' AND o.total > 100 AND o.created_at >= '2026-01-01'
当 WHERE 条件数量较多时，AND 必须换行后顶格对齐，不能缩进到与 WHERE 同一列——否则视觉上会误认为是 WHERE 的子内容，而实际上它们是同级的布尔操作符。这一点在条件嵌套时尤其容易混淆。
子查询为何需要额外缩进一层？
子查询必须比外层多缩进4个空格，这是区分嵌套层级最直观的视觉标识。括号的位置也有讲究：左括号 ( 应跟随 SELECT 换行后顶格，内部再缩进；右括号 ) 单独成行，与对应的左括号垂直对齐。如果子查询不缩进，结构会变得模糊，尤其是嵌套两层以上时，很难分辨每段代码属于哪一层。示例如下：
SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_countFROM users u
这里，SELECT COUNT(*) 整体比外层 SELECT 多缩进4个空格；WHERE 条件又比子查询的 SELECT 多缩进4个空格——逐层递进，一目了然。另外，AS 别名必须与字段位于同一行，并尽量将多个 AS 对齐，便于横向扫读。切忌写成 order_count AS 这种反向格式。
空格与大小写的隐性影响
所有二元操作符（=、>、AND、BETWEEN）前后都必须保留空格；一元操作符如 NOT 后面不加空格，紧贴条件。关键字统一使用大写（SELECT、FROM），字段和别名采用小写或 snake_case，避免混用造成阅读干扰。典型错误包括：WHEREstatus='active'（缺少空格）、SELECT*FROM...（无空格且无字段列表）、AND(status='a'ORstatus='b')（OR 前后无空格）。这些问题看似微小，但在多人协作或长期维护中，会显著拖慢定位速度。真正困难的并非记住这些规则，而是坚持执行——尤其在快速编写临时查询时，很容易忽略缩进和空格。然而，只要有一次未按要求缩进，下次添加条件时就可能破坏整体结构。越是简单的查询，越应严格遵循规范，因为这类查询最常被复制、粘贴和改写。
