iLoveDevTool为什么 SQL 格式化值得定规范
一段典型的「事故 SQL」长这样：从日志里拷出来的单行查询，两三个 JOIN、五六个条件全挤在一起，改一个条件要在三百个字符里找位置。而同一段查询格式化后，JOIN 关系、条件分组、字段清单一眼可读——格式化的价值不是好看，是把查询的结构显性化，让 review 的人能看懂逻辑。
但「格式化」没有唯一正确答案：大写还是小写、缩进 2 还是 4、逗号在行首还是行尾，每支团队都有自己的偏好。没有规范时，代码库里会并存五种风格，diff 噪音淹没真实改动。这篇给一套可直接落地的默认规范，并说明如何用工具自动执行——规范的最高形态是「不用人记得」。
先给工具入口：SQL 格式化在线工具支持 20 种方言（MySQL、PostgreSQL、SQLite、ClickHouse、Snowflake 等），关键字大小写、缩进宽度、语句间空行都可调，粘贴即出结果，还能一键压缩回单行。下面的规范建议都可以用它当场验证。
关键字大小写：选一派，然后自动化
两大流派的真实差异：
| 流派 | 主张 | 常见于 |
|---|---|---|
大写（SELECT … FROM） |
关键字醒目，与字段名/表名区分强 | 传统 DBA、Oracle 系、教材 |
小写（select … from） |
现代等宽字体下大写反而降低可读性，输入成本低 | 新兴团队、ORM 混用场景 |
我们的建议：跟随团队主流，没有主流就选大写——它与后续要讲的「字段小写」形成最大对比度。落地的关键不是选哪派，而是让工具贯彻：在线工具的关键字大小写选项选「大写」，粘进去的任何风格出来都统一；编辑器侧配 SQL Formatter 类插件（多数底层是同一个 sql-formatter 引擎），保存时自动格式化。
注意一个边界：大小写选项只作用于关键字，不动你的数据——WHERE name = 'Apple' 里的 'Apple' 原样保留。
缩进与折行：2 还是 4，以及字段列表怎么排
- 缩进宽度：2 空格对 SQL 更友好——JOIN 与子查询的层级天然深，4 空格会快速把字段推到屏幕右侧。跟随代码库主流约定时另说。
- 字段列表一列一行：
SELECT后多个字段各占一行，尾随逗号（行尾逗号）——增删字段时 diff 只有一行。 - JOIN 条件进 ON，过滤条件进 WHERE：
ON o.user_id = u.id管JOIN 关系，WHERE u.status = 'active'管结果过滤——格式化后这两类条件各自归位，混写是 review 时最常抓的坏味道。 - 子查询整体缩进一级，别名对齐在外层。
这些规则在格式化工具里大多自动完成（在线工具的默认输出就是上述排版），要自定义的只有缩进宽度与语句间空行。
压缩：格式化的反向需求真实存在
「把 SQL 压回单行」听起来反潮流，但两个场景高频：日志与监控里嵌入查询（一行好检索）、动态拼接 SQL 的代码审查（拉平看全貌）。压缩的正确性有个隐蔽坑：-- 行注释的换行被抹掉后，注释会吞掉后面整条语句——合格的工具会先把行注释转成 /* ... */ 块注释再折叠，语义不变。压缩时字符串里的连续空格也会合并为一个，含精确空格的匹配条件要用格式化而非压缩。
把规范固化下来
一套完整的落地动线：
- 定规范：用本文默认值（关键字大写、2 空格、字段一列一行）或团队投票微调，写进 CONTRIBUTING 一页纸。
- 工具执行：临时场景用在线 SQL 格式化按方言选好选项；日常场景配编辑器插件自动格式化。
- 存量迁移：老脚本批量贴进在线工具统一风格，再按 diff review——格式化不改变执行计划，性能零风险。
- 配套动线：查询结果的 JSON 用站内 JSON 格式化整理；数据回填表格用 JSON 转 CSV；CSV 数据要进查询试跑用 CSV 转 JSON。
常见问题
SQL 格式化用什么工具好？
看场景：临时粘贴一段查询用在线工具最快——本站的 SQL 格式化工具支持 20 种方言、关键字大小写与缩进可调，还能一键压缩回单行；日常写代码则配编辑器插件（VS Code 的 SQL Formatter 系插件底层与在线工具同源），把规范固化进保存动作。
SQL 关键字用大写还是小写？
两种流派都能自圆其说：大写派认为关键字醒目、与字段名区分强，是传统 DBA 风格；小写派认为现代等宽字体下大写降低了可读性、输入成本高。关键是全团队统一——格式化工具的关键字大小写选项（保持原样/大写/小写）能一键贯彻，比口头约定可靠。
SQL 缩进用 2 空格还是 4 空格？
跟随所在代码库的主流约定：前端仓库常是 2 空格，后端 Java/Go 仓库常是 4。单独维护的 SQL 文件推荐 2 空格——JOIN 层级深时 4 空格会快速把字段挤到屏幕右侧。工具里缩进宽度可调，迁移存量脚本时选与原文件一致的最省 diff。
格式化会改变 SQL 的执行性能吗？
不会。格式化只动空白、换行与关键字大小写，数据库解析后的执行计划完全相同；字符串内容原样保留。唯一要注意的是压缩（折叠为单行）时行注释会被转成块注释，语义等价但形态变化。