SQL格式化
⚡ 本地运行🔒 不上传数据🆓 免登录免费
SQL 格式化做的事情很单纯：把一行挤在一起的 SQL，按它的语法结构重新排版。它先做词法保护——把字符串字面量和注释用占位符保护起来，保证里面的内容一个字都不会被改动；然后识别关键字（大小写不敏感，select 和 SELECT 一视同仁）；再把 SELECT、FROM、WHERE、JOIN、GROUP BY、ORDER BY、LIMIT 这些子句关键字各自放到新行开头；遇到括号就缩进一级，子查询和函数参数一层层展开。关键字大写只是视觉规范——SQL 关键字本来就不区分大小写，大写纯粹是为了让结构更醒目，不改变任何语义。需要说明的是，本工具是轻量词法实现，不是完整的 SQL 解析器：它只管排版，不管语法对错，写错的 SQL 格式化完依然是错的。
典型用法有三类。第一，读别人的 SQL：从慢查询日志、ORM 打印的日志里拷出一行几百个字符的 SQL，贴进来格式化，JOIN 条件、WHERE 过滤、GROUP BY 分组各占一行，慢在哪一眼就有数。第二，调试 SQL 报错：少个逗号、括号不配对是最常见的低级错误，格式化之后缩进一错位，问题行直接暴露出来，比肉眼数括号快得多。第三，代码评审和写文档：把格式化好的 SQL 贴进 PR 描述、wiki 或故障复盘文档，可读性完全不是一个级别，评审人不用再跟挤成一团的单行 SQL 较劲。
边界情况要心里有数。字符串和注释是安全区：比如 LIKE 'a%and%' 里面的 and 不会被当成逻辑关键字换行，注释里的 SELECT 也不会被大写。但反过来也意味着，工具不会帮你发现字符串里写错的东西。方言差异：MySQL、PostgreSQL、SQLite、SQL Server 的通用 SELECT/INSERT/UPDATE/DELETE 语法都没问题；方言特有写法（比如 T-SQL 的 TOP n、SQL Server 的方括号标识符）会被当成普通词原样通过，格式化照常进行，只是不做语法校验。超大 SQL（几万行）在浏览器里也能跑，只是会慢一两秒。注释默认保留；但点「压缩」时会去掉注释——因为单行压缩后，行注释会把后面所有内容都注释掉，去掉是保护你。关键字大写可以关掉，关了就只做换行和缩进。
最后提醒两点。第一，格式化只改空白、换行和关键字大小写，逻辑零变化，格式化前后做一次 diff 就能验证，执行结果完全一致。第二，再好看的排版也救不了慢查询：格式化是帮你「看懂」SQL 的第一步，看懂之后该加索引加索引、该改写改写，那是下一步的事。
使用方法
- 把 SQL 粘贴进输入框（或点「填入示例」先看效果）。
- 按需勾选「关键字大写」，点「格式化」得到排版后的 SQL。
- 点「复制结果」贴回编辑器、PR 或文档；想压成一行就用「压缩」。
常见问题
格式化会改变 SQL 的语义吗？
不会。工具只改空白、换行和关键字大小写；SQL 关键字本来就不区分大小写，字符串字面量、注释和标识符原样保留。格式化前后 diff 对比一下就能确认，执行结果完全一致。
支持哪些数据库方言？
MySQL、PostgreSQL、SQLite、SQL Server 的通用语法（SELECT/INSERT/UPDATE/DELETE、JOIN、子查询、GROUP BY 等）都没问题。方言特有写法如 T-SQL 的 TOP n、方括号标识符会被当成普通词原样通过——格式化照常，但本工具是轻量美化器不是语法检查器，语法报错请看数据库返回的信息。
我的 SQL 会上传到服务器吗？
不会。所有计算都在浏览器本地完成，页面不发任何网络请求，生产库的敏感 SQL 也可以放心贴。
注释会被删掉吗？
点「格式化」时注释完整保留（行注释和块注释都是）。只有「压缩」会去掉注释，因为单行注释在压成一行后会注释掉后面所有语句，去掉是为了避免事故。
格式化后的 SQL 能直接执行吗？
可以，逻辑零变化。建议第一次使用时 diff 确认一次；之后对生产库操作前，依然建议先在测试环境跑一遍——这是好习惯，跟格式化无关。