粘贴一条查询，工具会按人阅读 SQL 的方式排版：每个子句一行，按层级缩进，被识别为关键字的词按你选择的大小写书写。它是开发者工具家族里最小的一个，原因很实在——排版从不拒绝任何输入，因为它从不假装理解语法。它先对带引号的字符串、带引号的标识符和注释分词，使它们永不被触碰；其余不认识的内容逐字符复制。
SQL 格式化器 - Danfio
https://danfio.com/tools/sql-formatter/ - 从本页打印
格式化后的 SQL
9 行
查询在顶层分号处被拆成 一条语句，每个子句一行，并按层级缩进。只有格式化器认识的关键字改变大小写；每个带引号的标识符和字符串字面量都逐字复制。
SELECT u.id, u.email, COUNT(o.id) AS orders FROM users u JOIN orders o ON o.user_id = u.id WHERE u.active = true GROUP BY u.id, u.email ORDER BY orders DESC LIMIT 10;
可以复制，也可以下载。查询表达的仍然是原来的意思：没有重排任何内容，也没有丢弃任何内容。
让它成为一个页面而不是一个命令行步骤的，是结果旁边印出的诚实说明。只有被识别的关键字会改变大小写，括号留在它们开始的那一行，语句只在顶层的分号处切分，任何内容都不会被重排或丢弃。函数调用绝不会被拆成两半，名为 `"SELECT"` 的列仍然是 `"SELECT"`，格式化器没见过的方言扩展原样保留——所有这些都会被写明，而不是留到代码评审时才发现。
面向真实数据库的格式化器需要读懂语法，因为判断一个词是关键字还是列名，会改变换行可以落在哪里。这个工具刻意走了一条更轻的路径：先认出绝不能碰的内容——带引号的字符串、带引号的标识符和注释——再把认识的关键字改成所选大小写，在总会开启新行的子句前断行，包括 SELECT、FROM、WHERE 等，最后按括号深度缩进。这个承诺比完整的 SQL 格式化器小，页面每次都会说明，而不是暗示自己懂你的方言。
结果之所以可信，理由很具体：格式化器从不重组它看不见的东西。括号留在自己的行上，`IN (1, 2, 3)` 和 `left(name, 3)` 原样输出；函数调用里的 `;` 不会结束语句；无法识别的词法单元逐字符复制。一切都在标签页里运行，不上传任何内容，静态页面已经携带用示例格式化好的查询，所以在任何人输入之前它就有用。
带引号的字符串、带引号的标识符和注释会在其他处理看到它们之前先被识别出来，并且全部逐字复制。写成 `"SELECT"` 的标识符是列名，不是关键字，因此绝不会被改大小写。像 `'WHERE x = 1'` 这样的字符串字面量是数据，不是子句。结果是：拼写特殊的查询，在真正按字面含义生效的部分会完整保留那种拼写。
被识别的关键字列表是固定且克制的——各子句、连接词、运算符，例如 AND、OR、IN、LIKE、IS NULL 等。列表之外的一切都逐字符复制：方言扩展、自定义运算符、碰巧长得像关键字的列名。
认出这些内容之后，格式化器会在那些总会开启新行的子句前断行——SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY、LIMIT、OFFSET、UNION、VALUES、SET、RETURNING——并在 JOIN 和 ON 真正引入连接时同样断行。结果就是人阅读时的形状：查询逐条列出，一个子句一行，不猜测表达式该在哪里折行。
缩进跟随括号。`count(o.id)` 这样的函数调用与函数名粘在一起，不产生缩进；而 `IN (a, b, c)` 这样的分组，会把列表缩进到左括号下方。括号本身从不移动：函数调用绝不会被拆成两半。
括号里的逗号到底分隔的是参数还是列表项，取决于外面的函数或运算符；不读取语句结构的排版器只能猜，而猜错就会让一段本来正确的 SQL 读起来有歧义。因此这里宁可保持原样，让布局始终可解释。
被识别列表里的关键字会按你选择的大小写书写——大写（SELECT、FROM、WHERE）或小写（select、from、where）。页面会逐词比较两次结果，统计这个设置实际改动了多少个词，因此结果旁边的数字是你的选择带来的真实效果，而不是估计。
带引号的标识符和字符串字面量绝不会改变大小写。所以名为 `"SELECT"` 的列在 lower 模式下仍然是 `"SELECT"`，字符串字面量也会保留数据所需的任何大小写。
关键字大小写只影响书写风格，不改变 SQL 的语义；同一套排版在两种模式下完全一致，因此可以并排比较两次结果，确认被改动的只有你能看见的那些词。不同方言对带引号标识符的处理并不相同，有的区分大小写，有的不区分，所以工具选择完全不碰它们。
格式化器不校验 SQL，也不声称能校验。它排版自己认得的词法单元，其余逐字复制，因此一条根本跑不通的查询仍会得到整齐的排版——格式化器是排版工具，页面从不假装它是别的东西。
语句只在顶层分号处切分，所以一起粘贴的多条查询会被依次处理并计数。不重排任何内容，也不丢弃任何内容：格式化后的文本与输入所说的完全一致，只是字节重新排列，需要改大小写的词按选择改了。校验和优化是另外两类工具的工作，它们才需要理解完整的语句结构和方言知识。
示例使用页面自带的默认输入，只改设置；下面的结果与你在页面上看到的完全一致。
粘贴查询: select u.id, u.email, count(o.id) as orders from users u join orders o on o.user_id = u.id where u.active = true group by u.id, u.email order by orders desc limit 10;
格式化后的 SQL
9 行
查询在顶层分号处被拆成 一条语句，每个子句一行，并按层级缩进。只有格式化器认识的关键字改变大小写；每个带引号的标识符和字符串字面量都逐字复制。
语句数: 1 · 行数: 9 · 字节数: 167 B · 改动大小写的词数: 13
每个子句各起一行，被识别的关键字转为大写。
粘贴查询: SELECT id, name FROM users WHERE active = true ORDER BY name; · 关键字大小写: 小写 - select、from、where
格式化后的 SQL
5 行
查询在顶层分号处被拆成 一条语句，每个子句一行，并按层级缩进。只有格式化器认识的关键字改变大小写；每个带引号的标识符和字符串字面量都逐字复制。
语句数: 1 · 行数: 5 · 字节数: 62 B · 改动大小写的词数: 5
排版完全相同，只是被识别的关键字写成小写。
粘贴查询: insert into log (msg) values ('hi'); select count(*) from log;
格式化后的 SQL
5 行
查询在顶层分号处被拆成 2 条语句，每个子句一行，并按层级缩进。只有格式化器认识的关键字改变大小写；每个带引号的标识符和字符串字面量都逐字复制。
语句数: 2 · 行数: 5 · 字节数: 62 B · 改动大小写的词数: 6
每个顶层 `;` 结束一条语句，因此结果面板会把两条都计入。
不会。排版在这个标签页里的 JavaScript 中完成，结果面板由页面上已有的内容构建，下载是本地创建的 blob。查询里常常包含数据、表结构细节或凭据，因此这里完全不接触服务器。
因为在括号里，不读取语句结构的格式化器必须猜逗号结束的是参数还是列表项，以及该缩进多深。这个工具从不猜：`IN (1, 2, 3)` 和 `left(name, 3)` 原样输出，只有在空间足够时，列表才会缩进到左括号下方。你能理解的排版，胜过工具替你编出来的排版。
不会，它也不声称会。它对绝不能碰的内容保持原样，把认识的关键字改成所选大小写，其余逐字复制——所以一条根本跑不通的查询仍会得到整齐的排版。校验需要针对你的方言的完整读取器；格式化器是排版工具，页面会明确说明这一点。
不会。带引号的标识符会在其他处理之前被分词并逐字复制，所以写成 `"SELECT"` 的列在两个方向上都保留这种拼写，字符串字面量也保留自己的大小写。只有被识别关键字列表中、且未被引号包裹的词，才会改变大小写。
可以，计数也会随之更新。无论选择哪种大小写，排版都完全相同——改变的只是被识别词的拼写——所以你可以比较两次结果，清楚看到这个设置改动了哪些词。
最近复核于 2026-10-07.
本页在您的浏览器本地运行，请保留原文件备份；不涉及财务建议。 阅读完整免责声明。
Danfio 中文在线工具