🗄️ SQL 格式化
美化或压缩 SQL 查询。支持 SELECT / INSERT / UPDATE / DELETE / JOIN / WITH。
完全免费
无需注册
浏览器内完成
5 种语言
深色模式
📖 常见的坑
把 SQL 格式化得更易读（也可反向压缩）。处理全部在浏览器内完成，查询不会被发送到任何地方。它只改变排版，并不校验语法——跑不通的查询同样会被格式化；MySQL、PostgreSQL、SQL Server 等方言的私有语法，排版结果也可能不自然。请把「实际执行验证」视为同一步骤的一部分。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 格式化后结果变了 | 原因几乎都是注释与字符串字面量的处理。-- 形式的注释作用到行尾，因此换行位置一变，被注释掉的范围也随之改变。当格式化把一行拆成多行的瞬间，原本生效的条件可能整段落入注释，或者反过来跳出注释。同理，压缩字符串字面量中的换行与空格，也会改变 LIKE 的匹配结果。 |
请用 /* … */ 而非 -- 书写注释：其作用范围是显式的，重新排版也不会改变语义。为确认没有意外变化，请对比格式化前后的 EXPLAIN 执行计划。若计划相同，至少在优化器看来这是同一条查询。 |
| 把格式化后的查询直接嵌进代码 | 把变得易读的 SQL 作为字符串贴进代码时，用字符串拼接插入值就是 SQL 注入。格式化过程中处理的是带有字面量值的查询，于是顺手写成 "WHERE id = " + id 就成了阻力最小的路径。经由格式化工具的这一步，正是最容易出这种事故的时刻。 |
值一律使用占位符：写成 WHERE id = ? 或 WHERE id = :id，实际的值交给驱动传递。占位符无法覆盖的是表名、列名与 ORDER BY 的方向，这些应通过白名单比对解决（例如只放行 ASC 或 DESC）。请养成习惯：在格式化后仍然易读的阶段，用眼睛确认没有残留的字面量。 |
| 格式化并不能让慢查询变快 | 显而易见，格式化对执行计划毫无影响。它可能让你看清原因，但那是对阅读者的帮助，与数据库无关。SQL 慢的原因绝大多数是索引没有被使用，这与写法是否整洁毫不相干。 | 请执行 EXPLAIN ANALYZE，查看实际读取了多少行。只返回 10 行却扫描了 100 万行，原因就在那里。常见元凶是在 WHERE 子句中对列施加函数（WHERE DATE(created_at) = ...），这会使索引失效；改写为范围条件 WHERE created_at >= ... AND created_at < ... 即可恢复。把 SELECT * 改为只取所需列，有时还能让覆盖索引生效。 |
若目标是统一团队的书写风格，请把 linter 放进仓库，而不是每次都来这里格式化。像 sqlfluff 这类工具不仅管排版，还能检测命名规范与危险写法（SELECT *、没有 WHERE 的 UPDATE 等）。在 CI 中对迁移文件运行它，评审意见就会从「可读性」转向「设计」。本页面真正适用的场景是：别人丢来一段难读的查询，你需要当场把它变得可读一次。
📖 使用方法
-
1
设置操作和选项选择美化或压缩,然后设置缩进大小和关键字大小写。
-
2
输入 SQL将 SQL 查询粘贴到左侧输入框。点击示例按钮加载包含 SELECT、JOIN 的复杂示例。
-
3
复制结果格式化或压缩的 SQL 显示在右侧。点击复制按钮将其复制到剪贴板。
❓ 常见问题
支持哪些 SQL 方言？
支持标准 SQL 及 SELECT、INSERT、UPDATE、DELETE、WITH、JOIN 等主要语法。
注释会保留吗？
美化模式下注释(--, /* */)会保留。压缩模式下注释会被删除。
字符串字面量的内容会被修改吗？
不会。字符串字面量（单引号中的值）不受关键字大小写或空白更改影响。
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。