SQL 语句格式化

SQL 格式化的典型场景

这个工具不是“功能演示”，而是希望覆盖你日常真正在做的几类工作：

• 排查线上问题：从慢查询日志里复制一整行 SQL，格式化后更容易看出 WHERE、JOIN、GROUP BY 哪一段可能有问题。
• 代码审查/走查：把 PR 里风格杂乱的 SQL 统一格式化，方便 Reviewer 只关注“是不是这条 SQL”而不是被排版干扰。
• 写技术文档：把业务里典型 SQL 片段美化后贴到 Wiki/接口文档里，后续接手的人更容易理解。
• 对比不同版本：先用“压缩”把两段 SQL 都挤成一行，再用 diff 工具对比差异（比如只改了一个条件）。

推荐的使用习惯

1. 先格式化、再思考：拿到一段难读的 SQL 时，第一步先丢进这里格式化，再去做 EXPLAIN/调优。
2. 固定风格：团队内部约定关键字大写、缩进空格数等参数，减少“因为排版不同看不出其实是同一条 SQL” 的情况。
3. 谨慎改动条件：格式化后的 SQL 更容易复制到编辑器中逐条修改条件；每次修改后，建议在目标数据库执行一次语法检查。

示例：从日志到可读 SQL

假设线上日志里只有这样一行：

SELECT u.id,u.name,o.id oid,o.amount FROM users u JOIN orders o ON u.id=o.user_id WHERE u.status='active' AND o.created_at >= '2025-01-01' AND o.deleted_at IS NULL ORDER BY o.created_at DESC LIMIT 100;

格式化后会类似：

SELECT
    u.id,
    u.name,
    o.id AS oid,
    o.amount
FROM users AS u
JOIN orders AS o ON u.id = o.user_id
WHERE u.status = 'active'
  AND o.created_at >= '2025-01-01'
  AND o.deleted_at IS NULL
ORDER BY o.created_at DESC
LIMIT 100;

这种结构更方便你在 WHERE 与 JOIN 段之间来回切换，逐个排查条件是否符合预期。

结果观察重点

格式化完成后，优先看 SELECT 字段列表、JOIN 条件和 WHERE 过滤条件是否被拆成了清晰的分段；如果压缩后的语句长度突然明显缩短，也要确认没有误删注释之外的内容。准备交给同事复核或贴到文档时，建议保留格式化版本；准备做文本比对时，再切换到压缩版本。

常见问题

格式化会不会修改 SQL 语义？ 正常情况下不会，工具主要调整空格、缩进和换行；但在复制回业务代码前，仍然建议在目标数据库做一次语法检查。

历史记录会上传吗？ 不会，历史记录只保存在当前浏览器本地，用于你回看最近处理过的 SQL 片段。

压缩模式适合什么场景？ 适合日志采集、接口传输和 diff 对比；需要给人阅读时，优先使用格式化版本。