如何阅读与格式化 SQL：从一行乱码到整洁代码

如果你曾在数据库上工作过，一定见过：一个从工具或 ORM 里出来的查询，被压缩到一行，join 和 WHERE 子句挤在一起。它也许能跑，但你不逐字符读上一遍根本看不出它在干嘛。

这篇指南解释为什么可读的 SQL 重要、格式化和压缩做什么，以及如何一步清理拥挤的查询。

为什么可读的 SQL 重要

可读的 SQL 不是奢侈品——它是团队抓 bug 的武器。一个微妙的逻辑错误很容易藏在 200 字符的一行里。同样的逻辑，每个子句各占缩进的一行，在代码评审里就不可能错过。

格式化还让 diff 有意义。当团队每个人用一致的键字大小写和缩进时，pull request 显示的是实际逻辑变更，而不是一墙重排空白。如果你见过一个 90% 的 diff 只是重格式化的 PR，你就明白为什么这重要了。

SQL 格式化器做什么

格式化器把查询拆成可读形式：

键字大小写——select 还是 SELECT，还是 Select。一致的写法让键字极易辨认。
缩进——每个子句（SELECT、FROM、WHERE、GROUP BY、JOIN）各占一行，嵌套子查询缩进显示其结构。
换行——查询被拆成多行，长查询变得可扫描。

相反，压缩做相反的事：去掉所有多余空白和换行，产生尽可能小的查询。这是你想把查询嵌进日志、URL 或 config 字符串时需要的。

要小心的一点

任何 SQL 格式化器最大的风险是触碰字符串字面量。一个天真的格式化器看到带引号的文本，可能试图在其内部重排，把 'New York' 变成会破坏查询的东西。好的格式化器完全不动字符串字面量和注释——格式化只作用于键字和结构，绝不影响引号内的文本。如果格式化器「修正」了你的数据值，那就是你不该用于真实工作的格式化器。

SQL 方言

不同数据库有各自的怪癖——MySQL、PostgreSQL、SQLite 等语法和函数名略有差异。好格式化器理解主要方言的常见约定，因此无论查询是去 MySQL 还是 Postgres 数据库，都能以同样方式格式化，而不会弄乱方言专有语法。

快速参考

可读的 SQL 是团队抓 bug 的方式：微妙的逻辑错误藏得进 200 字符的一行，却藏不进每子句一行的缩进查询。
一致的格式让 diff 有意义——PR 显示的是逻辑变更，而不是一墙空白。
格式化器统一键字大小写、缩进与换行；压缩则反其道，产出最小的 payload。
绝不让格式化器碰字符串字面量和注释——如果它「修正」了你的数据值，就不能用于真实工作。
方言各异（MySQL、PostgreSQL、SQLite）；好格式化器尊重目标数据库的语法。

开始使用

如果你有一个很难读的查询——或想让你的 SQL 与团队一致——SQL 格式化工具会把它变成干净、正确缩进的代码，键字可选 UPPERCASE 或小写，而且不碰你的数据。如果你在 SQL 之外还处理 JSON，JSON 格式化工具也会以同样方式让你的 API payload 保持可读——或者从什么是 JSON开始入门。