所有工具

SQL格式化与美化

使用我们的SQL格式化与美化工具轻松格式化和美化您的SQL代码，提高代码可读性。

2 个评分中的 5 个

SQL格式化与美化是一款免费工具，可将 SQL 代码整理成更易阅读、版式更统一的形式。

SQL 格式化会改变什么？

SQL 格式化会调整查询语句的呈现方式，让子句、表达式和嵌套结构更容易理解。它通常会在 SELECT 列表、JOIN 子句、WHERE 条件、子查询和 CASE 表达式等元素周围添加换行和缩进。

格式化不应改变查询的预期结果。不过，不同 SQL 方言之间存在差异，仅凭格式化无法证明语句的含义完全没有变化。针对生产数据运行之前，请检查生成的 SQL，尤其是使用了特定数据库厂商的运算符、过程式扩展或特殊引号规则时。

阅读第三方查询、审查自动生成的 SQL、调试较长的语句或准备提交拉取请求时，格式化工具都很有用。统一的版式还能减少无关的空格差异，让你更容易比较代码改动。

如何格式化 SQL？

将语句粘贴或输入 SQL 字段，然后提交，即可在 美化的SQL 中获得格式化后的版本。输入内容会通过 HTTPS 发送到服务器处理，但不会被存储。

复制完整语句，包括需要保留的所有公用表表达式，并在结果中核对注释以及结尾的分号。
尽量将完整语句输入 SQL 字段，不要只格式化孤立的代码片段。
查看 美化的SQL 中的结果，特别留意嵌套表达式和特定 SQL 方言的语法。
部署前，先在合适的开发或预发布环境中运行格式化后的语句。

如果涉及敏感的数据库工作，在将查询文本发送到任何基于服务器的工具之前，请先确认你所在组织的相关政策。若密码、访问令牌、个人数据和机密字面值并非理解查询所必需，请先将其删除。

如何阅读美化后的 SQL？

阅读结果时，应顺着缩进和子句边界理解语句，不要把新版式当作语句有效的证明。顶层的 SELECT、FROM、WHERE、GROUP BY 和 ORDER BY 通常会分别占据独立的行或缩进层级，因此更容易区分。

缩进后的子查询可以看出内部查询结果在外层语句中的使用位置。
对齐的条件便于检查 AND 和 OR 的优先级。不过，默认情况下 AND 的优先级高于 OR，逻辑分组仍由括号决定。
分开的 JOIN 子句有助于看清每个 ON 条件对应哪张表。
展开的 SELECT 列表更容易发现缺失的逗号、重复的列和含义不明确的别名。
清晰可见的 CASE 分支有助于审查者对应 WHEN、THEN、ELSE 和 END 关键字。

在 SQL 中，带引号的字符串、数字、标点符号和注释都承载语义，因此需要逐一检查，不能认为它们只是显示形式的一部分。根据数据库及其字符编码的不同，带重音符号的字符或非拉丁字符可能可以合法地出现在字符串字面量和带引号的标识符中。

简单的格式化示例

先看下面这条紧凑的输入。

输入：SELECT id,name FROM customers WHERE active=1 ORDER BY name;

一种易读的格式化结果如下。

输出：SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

对于包含 JOIN 的查询，缩进带来的改善会更加明显。

输入：SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

易读的输出可以将 SELECT、FROM、JOIN、ON 和 WHERE 分别放在不同的行，同时保留比较表达式 o.total > 100。不同格式规范采用的大小写、空格和换行位置可能不同，因此这些示例只用于展示版式，并不代表固定的代码风格。

格式化能发现 SQL 错误吗？

不能。美化 SQL 不等同于使用数据库解析器进行验证。此工具提供的是格式化后的 SQL，不能将其当作语法检查器、架构检查器或执行计划分析器。

不过，更清晰的版式仍可能帮助你在审查时发现疑似错误。常见问题包括 SELECT 列表中缺少逗号、括号不匹配、带引号的字符串没有正确结束、JOIN 缺少预期条件，以及 AND 或 OR 表达式的分组不正确。它也可能让作为未加引号标识符使用的保留字更容易被发现。

有些问题必须结合目标数据库才能确定。PostgreSQL 接受的语句，在 Microsoft SQL Server、MySQL、Oracle Database 或 SQLite 中可能需要修改。表不存在、列未知、数据类型不兼容和权限不足等问题，通常需要由数据库引擎或支持相应方言的开发工具进行诊断。

哪些情况不值得格式化 SQL？

如果 SQL 已经采用统一格式，或者只会由机器读取，通常没有必要再次格式化。重新整理自动生成的查询可能会在版本控制中产生大量无意义的改动，却无法改善生成这些查询的程序。

在以下情况下，格式化也可能不是合适的处理方式：

迁移文件已经签名、计算校验和，或需要按字节逐一比对。
精简或紧凑的查询嵌入在对大小敏感的构件中，而且不需要人工审查。
当前任务是验证、执行计划分析或性能调优，而不是提升可读性。
查询包含机密值，组织政策不允许将其发送到基于服务器的服务。

如果需要对整个代码仓库进行可重复的格式化，支持相应 SQL 方言的命令行格式化工具可能更合适，因为其配置可以与代码一起提交。对于包含 SQL 的结构化 API 载荷，可以使用 JSON验证与美化工具检查外层 JSON，但其中的 SQL 仍需使用专门的 SQL 工具处理。

常见问题

格式化 SQL 会改变 NULL 的行为吗？

不会。空格和缩进不会改变 SQL 的三值逻辑，也不会影响 NULL 的行为。即便如此，仍应检查 column = NULL 之类的表达式，因为它们通常应写成 IS NULL，而格式化工具不会纠正这种语义错误。

可以一次格式化多条 SQL 语句吗？

目前没有文档说明支持一次处理多条 SQL 语句。请逐条格式化。

输入中保留注释安全吗？

不能仅因可执行 SQL 中没有敏感字面值，就认为保留注释是安全的。注释仍可能包含工单编号、内部主机名、客户信息或运维备注。将文本发送到服务器之前，请同时检查行注释和块注释。

SQL 关键字应该大写还是小写？

两种写法通常都可以，因为许多数据库引擎在处理未加引号的关键字时不区分大小写。请遵循代码仓库现有的规范，并谨慎处理带引号的标识符，因为某些数据库会保留或区分其大小写。

运行格式化后的查询前要检查什么？

请确认目标数据库使用的 SQL 方言，检查 WHERE 和 JOIN 条件，并核实 UPDATE、DELETE 及架构变更语句的事务边界。高风险查询应先在开发或预发布数据库中运行，最好使用具有代表性的数据并准备妥善的备份。