SQL 格式化

按子句换行缩进，可一键关键字大写，便于阅读复杂查询

SQL 格式化：样式惯例、执行顺序与常见的误改风险

格式化做了什么，没做什么

格式化只做排版：按子句换行、按嵌套层级缩进、可选把关键字转成大写。它不会：

校验语法。它不是解析器（parser），而是按关键字与括号做重排。所以一条有明显语法错误的 SQL 也能被"格式化"出一份看起来整齐的输出。语法正确性要靠数据库或专门的 linter 检查。
优化性能。排版与执行计划没有任何关系。慢查询的解法是索引、统计信息、执行计划分析，不是换行。
理解语义。它不知道 select 出现在字符串字面量里应该被当成普通文本，这是判断实现好坏的关键点。

最后一条值得说明：SELECT 'select from where' AS x 里的 'select from where' 是一个字符串值，不能被当成子句。实现如果只靠正则匹配关键字，会把引号里的内容一起改掉。工具会跳过字符串字面量内部（单引号、双引号以及反引号包裹的标识符），不会改动其中的内容。

样式惯例

选择	惯例	理由
关键字大小写	大写 `SELECT`	与标识符、函数名区分开，长查询里更容易扫读
缩进	2 或 4 空格	团队统一即可；不要用制表符与空格混排
主子句换行	FROM、WHERE、GROUP BY 各起一行	让每个子句的作用范围一眼可见
逗号位置	前置（`, col`）或后置	前置的"尾逗号"在增删字段时 diff 更干净
JOIN 对齐	每个 JOIN 单独一行并缩进其 ON	多表连接的逻辑最容易在这里看错

关键字大写是最普及的一条，但不是硬规则——有些风格指南要求全小写（因为 SQL 本身不区分关键字大小写，书写少一次 Shift）。关键是团队一致，混用才是最影响阅读的。工具提供开关，可以按你的习惯选。

读 SQL 的顺序与实际执行顺序不同

这是理解复杂查询最有用的一件事：写成文字的顺序和数据库实际计算的顺序不一样。

书写顺序	执行顺序
SELECT	1. FROM（确定数据源）
FROM	2. JOIN / ON（连接）
WHERE	3. WHERE（过滤行）
GROUP BY	4. GROUP BY（分组）
HAVING	5. HAVING（过滤分组）
ORDER BY	6. SELECT（计算输出列）
LIMIT	7. DISTINCT / ORDER BY / LIMIT

由此可以直接推出几条常见困惑的解释：

为什么 WHERE 里不能用 SELECT 里的别名。因为 WHERE 在 SELECT 之前执行，此时别名还不存在。（ORDER BY 里可以用，因为它最后执行。）
为什么 HAVING 能筛聚合结果而 WHERE 不能。WHERE 在分组之前、HAVING 在分组之后。
为什么 WHERE 里写聚合函数会报错。聚合在 WHERE 之后才发生。

各数据库的方言差异

格式化不改变语句，但读一份格式化后的 SQL 时要注意方言带来的差异：

差异点	要注意的
标识符引用	MySQL 用反引号，PostgreSQL / Oracle 用双引号，SQL Server 用方括号
分页	`LIMIT / OFFSET`（MySQL、PostgreSQL、SQLite）、`FETCH FIRST`（标准 SQL、Oracle 12c+、SQL Server）、`ROWNUM`（老 Oracle）
字符串拼接	`CONCAT()` 与 `\|\|` 各有支持
引号内的转义	单引号转义写 `''` 是标准；反斜杠转义在 MySQL 里默认开启，在 PostgreSQL 的标准字符串里不生效

如果要跨库迁移，光靠格式化看不出来——需要用专门的方言转换工具或人工审查。格式化的输出不能直接当作兼容性验证。

工具怎么用

粘贴 SQL，点格式化，按需勾选"关键字大写"。输出会按子句换行并缩进嵌套结构（子查询、括号内的条件）。这是可逆的纯排版操作，原始语义不变。用于评审前统一格式、整理日志里压缩成一行的长查询、以及读懂别人写的单行长 SQL。全部在浏览器本地处理，含生产库表名与字段的语句不会被上传。

常见问题

字符串里包含关键字会被误处理吗？

不会。工具会先把单引号字符串和注释用占位符保护起来，格式化完成后再还原，字符串与注释内容原样保留。

支持哪些数据库方言？

通用 SQL 子句都能识别，常见 MySQL / PostgreSQL / SQLite 写法均可。极少数方言特有语法可能不完美换行。

格式化后会改变查询结果吗？

不会。仅调整空白与换行，不改变任何语义。