哪些关键字会触发格式化输出里的换行？

一组固定的主要子句：SELECT、FROM、WHERE、INSERT、INTO、VALUES、UPDATE、SET、DELETE、CREATE、ALTER、DROP、ORDER、GROUP、HAVING、LIMIT、UNION、JOIN、LEFT、RIGHT、INNER、OUTER、CROSS、FULL、ON、AND、OR、BEGIN、COMMIT、ROLLBACK。它们都从单独一行、同一缩进层级开始。

uppercase、lowercase 和 capitalize 三个选项有什么区别？

uppercase 把关键字渲染成 SELECT，lowercase 渲染成 select，capitalize 渲染成 Select——首字母大写、其余小写。只有工具关键字列表里的词会被改大小写；表名、列名等标识符保留你输入的原始大小写。

压缩模式会保留我的注释吗？

不会。压缩会剥掉以两个连字符开头的单行注释，以及斜杠星号之间的块注释，然后把所有连续空白折叠成一个空格。格式化模式会原样保留注释。

为什么 AND 会另起一行，而不是留在 WHERE 旁边？

AND 和 OR 属于会换行的子句列表，所以每个条件各占一行。这种处理可预测但很扁平：没有悬空缩进把条件在视觉上嵌套进 WHERE，所以一长串 AND 读起来像一串并列项，而不是一棵树。

格式化会改变查询的执行方式吗？

不会。格式化器只调整空白、改变已识别关键字的大小写，这两者 SQL 都会忽略。它不重排、不重写、不校验任何内容，所以语句含义保持不变。

它会对子查询和括号做缩进吗？

不会按嵌套深度缩进。格式化器只跟当前词元是否开启一个子句，所以括号里的 SELECT 会和外层查询处于同一缩进层级另起一行。短查询可读，但深层嵌套只会得到一层缩进。

SQL 格式化工具 | HandyTools Hub

挤在一行里的 SQL 很难审查，藏在末尾的 WHERE 子句更是容易被漏掉。这个格式化器把粘贴进来的查询铺开，让主要子句各占一行并缩进，关键字大小写和两空格或四空格缩进都可以选。它还有一个压缩模式做相反的事：把 SQL 压成一行，方便放进日志、URL 或配置文件。

如何使用

把查询粘贴或键入输入面板。工具会边输入边格式化，输出实时更新。
点击 Format 铺开查询，或点击 Minify 压缩它。
从第一个下拉框选择关键字大小写——uppercase、lowercase 或 capitalize。
从第二个下拉框选择两空格或四空格缩进宽度。
看面板下方的字符数统计，了解这次转换增加了还是减少了多少，然后点击 Copy 取走结果。

编辑器里按 Ctrl+Enter（或 Cmd+Enter）可重新执行 Format。

逐词看变化

格式化器工作在词元上，而不是解析后的语法树。它先把字符串字面量和注释挪到一边，然后规范化逗号和括号周围的空白——逗号变成“逗号加空格”，左括号前强制加一个空格，括号内的空格被移除。结果按空白切分。

接着它遍历词元列表。当某个词元的大写形式是主要子句、且当前行尚不为空时，就输出一个换行，并用配置的缩进开启下一行。被识别的关键字按你的设置改写大小写，其余内容原样复制。

实际效果就是扁平、每个子句一行的布局。一个四子句查询变成四行缩进，每个 AND 和 OR 条件都在同一深度的独立一行上。

实操示例：一行查询

输入：

select id, name from users where status = 'active' and age > 18 order by name asc

用 uppercase 关键字、两空格缩进的 Format 输出：

SELECT id, name
FROM users
WHERE status = 'active'
AND age > 18
ORDER BY name ASC

注意字符串字面量 'active' 未被触碰，列清单留在 SELECT 行，而 ASC 被改写了大小写，因为它在关键字列表里。同一输入经过 Minify 变成：

select id, name from users where status = 'active' and age > 18 order by name asc

Minify 不改写关键字大小写，所以小写拼写保留下来。

再看一个带子查询的查询：

select name from users where id in (select user_id from orders where total > 100)

Format 产生：

SELECT name
FROM users
WHERE id IN (select user_id
FROM orders
WHERE total > 100)

有两点值得注意。内层 select 没有被改写为 SELECT，也没有另起自己的行——因为左括号和关键字粘在一起，生成的词元是 (select，既不匹配子句列表也不匹配关键字列表。一旦内层 FROM 和 WHERE 作为独立词元出现，它们就被识别并确实另起一行，而右括号仍粘在最后的 100 上。这在功能上是正确的，也比一整行长得多，读起来舒服，但它不是人手会写出的阶梯式缩进。这正是扁平的词元模型在起作用。

格式化和压缩的对比

行为	格式化	压缩
子句处换行	是	否
关键字改写大小写	是	否
剥离注释	否	是
折叠空白	部分	完全
最适合	代码审查、文档、调试	日志、URL、嵌入字符串

典型用法是先格式化再审查、嵌入前先压缩。因为压缩会删除注释，绝不要对注释里含有你日后需要信息的查询运行它。

字符串和注释如何被保护

这是让工具用起来安全的关键特性。在任何分词之前，每个单引号字符串都会被替换成类似 __STR0__ 的占位符，块注释替换为 __BC0__，行注释替换为 __LC0__。这些占位符是不可能被误认作关键字的惰性词，所以像 'Drop it' 这样的字面量永远不会被改写大小写或断行。格式化完成后，原件按顺序恢复。

压缩会彻底移除注释占位符并恢复字符串。有一个注意点：保护逻辑匹配的是任意两个单引号之间的内容，所以那些以不寻常方式转义引号的方言——字面量里的双写引号或反斜杠转义——可能让边界混淆，值得抽查。

基于词元格式化器的局限

关键字匹配是文本层面的。 名为 count 的列、或与关键字撞名的表别名会被改写大小写，名为 order 或 set 的标识符可能被推到新行。给这类标识符加引号通常能避免混淆。
没有嵌套深度。 子查询和带括号的表达式全都停在同一缩进层级。
不做语法校验。 格式错误的 SQL 和合法 SQL 一样被忠实格式化；工具不会告诉你查询写错了。
没有方言专属规则。 虽然能处理常见的 MySQL、PostgreSQL 和 SQLite 语法，但它不识别 RETURNING、LATERAL 这类方言专属关键字。
注释不会被重排。 在格式化模式下，很长的行内注释就停在它碰巧所处的位置。

SQL 格式化工具