编码解码哈希加密格式化时间转换开发生成文本处理网络工具其他工具
首页 / 格式化 / SQL格式化

SQL格式化

把 SQL 排版得更易读。

输入
结果

这个工具能做什么

这个工具解决的是一个很具体的阅读问题:SQL 语句挤成一整行时几乎没法看。ORM 框架打印到日志里的 SQL、慢查询日志里的记录、同事从聊天窗口贴过来的语句,往往是 SELECT ... FROM ... WHERE ... 一路平铺到底,关键字大小写还混乱。粘进来之后,工具把 SELECT、FROM、WHERE、JOIN、GROUP BY、ORDER BY 这类关键字统一大写,并在每个主要子句前换行,让语句的骨架一眼可辨。这是 sql格式化 里最基础也最常用的一步,目的是排版,不是重写。

它的工作方式本质上是一次轻量的词法处理。工具先把 SQL 文本按 token 切分,识别出字符串字面量(单引号包裹的内容)和注释,把它们整体保护起来,避免把 'FROM' 这种写在字符串里的词误当成关键字大写。剩下的 token 再去和 SQL 保留字表比对,命中的关键字转成大写,并在 SELECT、FROM、WHERE、JOIN、GROUP BY、HAVING、ORDER BY 等子句边界处插入换行。因为它只调整空白符和标识符的大小写,不解析完整语法树,所以处理快、结果可预期,但对深层嵌套的对齐能力有限。

最常见的用法是排查问题时的第一步预处理。比如你在应用日志里看到一条被 ORM 拼出来的单行长 SQL,怀疑它是慢查询的元凶,先丢进来 sql美化 一下,换行后就能顺着 WHERE 和 JOIN 条件逐行核对索引命中情况,再决定要不要加索引或改写。又比如做 code review 时,同事贴来的 SQL 大小写和缩进各写各的,用它统一 sql排版 后,几个人看的是同一套结构,讨论条件顺序和连接方式时不容易看漏。整理好的语句也方便直接贴进 Navicat、DataGrip 等客户端里执行。

需要留意的是,它做的是排版而非校验,不会检查你的 SQL 语法对不对,也不会改变执行语义——同一条语句格式化前后交给数据库跑,结果完全一致。对于复杂的嵌套子查询、CTE(WITH 子句)、窗口函数或超长的 CASE WHEN,这种轻量排版只能保证子句换行,缩进层级未必理想,通常还得手工微调几处。另外各家数据库方言略有差异,个别厂商特有的关键字可能不在通用保留字表里而不被大写,这属于正常边界,不影响语句本身。

SQL格式化是一个免费的在线工具,打开网页就能用,不用下载也不用注册。平时大家搜的“sql格式化”、“sql美化”、“sql排版”,说的都是这个。

常见使用场景

使用方法

  1. 把内容粘贴到输入框(生成类工具直接设置选项)。
  2. 按需要选择选项,点操作按钮。
  3. 结果出现在下方,点「复制结果」即可带走。

常见问题

格式化会改变 SQL 的执行结果吗?
不会。工具只调整空白换行和关键字大小写,不改动表名、字段、条件和值,字符串字面量与注释里的内容也原样保留,因此格式化前后交给数据库执行的结果完全一致。
支持哪些数据库的 SQL?
以通用 SQL 关键字为准,MySQL、PostgreSQL、SQL Server、Oracle 等主流数据库的常见语句大多能正确识别。个别方言特有的关键字可能不在保留字表里,不会被大写,但不影响语句结构。
关键字一定要大写吗,能保留原来的小写吗?
工具默认把识别到的关键字统一大写,这是较普遍的书写约定,也便于和标识符区分。如果你们团队规范要求小写关键字,需要在格式化后自己再替换调整。
为什么我的多层嵌套子查询排版还是有点乱?
这是轻量排版的边界。工具按主子句换行,但不重建完整语法树,对深层嵌套子查询、CTE 和窗口函数的缩进层级支持有限,这类语句通常还需要手工微调几行。
粘贴进去的 SQL 会被上传吗?
不会,格式化在浏览器本地完成,SQL 不会发送到服务器。含表结构或业务条件的语句可以放心粘贴处理。

相关工具

查看全部「格式化」工具 →

相关名词解释