SQL 格式化

方言选择器为什么重要

SQL 之所以称为标准，大致相当于英语拼写称为标准。每个引擎都实现公共核心，然后各自添加别家没有的语法；如果格式化器不知道你的目标引擎，它要么会误解这些语法，要么就静默地原样跳过不做处理。

这些差异并不冷僻。仅标识符引用方式就已经分家：MySQL 用反引号，PostgreSQL 和标准 SQL 用双引号，SQL Server 用方括号。假设了错误约定的格式化器，可能把带引号的标识符当成字符串字面量，并围绕一个根本不存在的边界重新折行。除引用方式外，还有 LIMIT 与 TOP 与 FETCH FIRST 之别、PostgreSQL 的 :: 转换运算符、T-SQL 中以 @ 开头的变量、BigQuery 用反引号包裹的项目路径，以及 Snowflake 的 QUALIFY 子句。选对方言，才能让这些保持完整。

缩进其实是一个 diff 决策

缩进宽度和关键字大小写看似只是外观，实际上决定了你的版本历史长什么样。格式化只有在保持一致时才有价值——一旦两个人对同一个文件用了不同的格式，每次提交都会夹带一片无关的空白改动，代码评审就此失效。选定一套配置，写进仓库，然后机械地执行。

关键字全大写是最常见的约定，在阅读密集查询时很有帮助，因为结构性词汇能与表名列名在视觉上分开。近年在把 SQL 当作普通代码、不喜欢"喊话"风格的代码库里，全小写也逐渐流行。而当你要格式化别人的查询、希望只调整排版而不改动其一个字符时，"保持原样"是正确选择——这样产生的 diff 是纯结构性的。

制表符与空格之争照旧，但 SQL 场景有个特有的细节：查询经常被粘进终端、工单系统和聊天工具，而这些地方常把制表符渲染成八列宽。用制表符缩进的深层嵌套查询，恰恰会在你最可能分享它的场合折行成一团乱麻。

格式化不会做的事

格式化纯粹是呈现层面的。它不会让查询变快，也不会改变优化器生成的执行计划。一个缩进优美的关联子查询，仍然是每行执行一次。性能问题请用 EXPLAIN，格式化只负责可读性。

它同样不做校验。本工具的解析足以重排文本，但它不是数据库引擎的解析器，一条列名拼错或缺少连接条件的查询，它照样会格式化得漂漂亮亮。排版整洁不等于语法正确，唯一有权判定查询是否有效的，是你打算执行它的那个数据库。

有一个值得与格式化一起养成的习惯是参数化。把值直接拼进字符串的查询，格式化之后只是让注入风险变得更易读，风险本身分毫未减。如果你发现自己正在格式化一段把用户输入直接拼接进文本的 SQL，那么首先需要修的显然不是格式。