SQL格式化工具sql-beautify实战：从安装配置到团队规范落地

代码评审那天，同事贴了一段六十多行的线上SQL，WHERE条件拼了三层子查询，ORDER BY 后面还塞了个 CASE WHEN，全部挤成一行。群里安静了半分钟，最后有人问：这SQL是拿什么写的，我连它查的是哪张表都看不出来。后来我花了半天时间，用 sql-beautify 把项目里的 SQL 脚本全部重新排版，又把规则写进团队规范，这种“考古式评审”才算结束。这篇内容就把 sql-beautify 的安装、配置、命令行用法和实际踩坑完整梳理一遍，给同样被 SQL 排版折磨的人一个可以直接抄作业的方案。

1. 为什么选中 sql-beautify：从一个让我头大的 SQL 片段说起

先看一段典型的“未格式化”SQL。这种代码在真实项目里太常见了，多表 JOIN、动态条件拼接、统计字段堆在一起，能写出来的人自己看得懂，换个人来看就是灾难。

sql复制SELECT a.id,a.name,b.order_no,b.amount,c.title FROM users a LEFT JOIN orders b ON a.id=b.user_id LEFT JOIN products c ON b.product_id=c.id WHERE a.status=1 AND b.pay_status=2 AND c.category_id IN (10,20,30) AND b.created_at>=DATE_SUB(NOW(),INTERVAL 7 DAY) ORDER BY b.created_at DESC LIMIT 100;

在编辑器里要横向拖滚动条才能看全，在终端里直接折成四五行。像 LEFT JOIN 和 WHERE 被淹没在一长串字符中间，肉眼根本分不清主从表的关联顺序。有一次排查一个慢查询，我花了二十分钟才从这种“压缩包”里找出 c.category_id IN (10,20,30) 是导致索引失效的元凶。格式化之后的同一段SQL是下面这样：

sql复制SELECT
  a.id,
  a.name,
  b.order_no,
  b.amount,
  c.title
FROM
  users a
  LEFT JOIN orders b ON a.id = b.user_id
  LEFT JOIN products c ON b.product_id = c.id
WHERE
  a.status = 1
  AND b.pay_status = 2
  AND c.category_id IN (10, 20, 30)
  AND b.created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
ORDER BY
  b.created_at DESC
LIMIT 100;

一眼就能看出查询主体、JOIN 关系、筛选条件。再看之前那行“压缩包”，浪费的时间根本不是技术问题，是排版问题。

1.1 sql-beautify 解决的核心痛点

sql-beautify 是一个基于 Node.js 生态的 SQL 格式化工具，解决的事情很聚焦：把混乱的 SQL 字符串解析成结构清晰、缩进统一、关键字风格一致的文本。它不会改写你的 SQL 逻辑，也不会帮你优化执行计划，它只做排版，但排版本身就能解决很多问题。

• 代码评审不用再把时间花在“这行到底怎么读”上，直接看结构就能聊逻辑。
• 排查慢查询时，格式化后的 SQL 更方便复制到执行计划工具里分析。
• 团队多人写 SQL 风格不一致时，格式化器是统一标准最省力的手段。

不需要考虑用它的场景也很明确：如果你只是偶尔写两句 SQL，IDE 自带的格式化就够了。sql-beautify 更适合那些需要批量处理 SQL 文件、要把格式化流程接入 CI 或 Git Hook、或者对输出风格有自定义要求的工程化场景。

1.2 和同类工具的一分钟横向对比

我在选型时简单对比过几个同类工具：Python 生态的 sqlparse、Node 生态的 sql-formatter、还有 Navicat / DBeaver 自带的格式化功能。