SQL 格式化踩坑：为什么格式化后 join 条件缩进全乱了

格式化工具让乱成一团的 SQL 瞬间变得工整可读——这是它的价值。但用了几轮之后你会发现：某些 SQL 格式化后反而更难读，甚至改变了原始逻辑的可读性。

这篇文章复盘 5 个格式化后反而踩坑的场景，给出来"什么时候格式化、什么时候不该格式化、格式化后必复查"的判断标准。

坑 1：多层 JOIN 缩进混乱

原始 SQL 靠肉眼对齐还能看清 join 层级：

SELECT u.id, u.name, o.total, i.price
FROM t_user u
LEFT JOIN t_order o ON u.id = o.user_id
LEFT JOIN t_order_item i ON o.id = i.order_id AND i.deleted = 0
WHERE o.total > 100

格式化之后变成这样（每个 ON 子句都自动缩进 8 个空格）：

SELECT u.id,
       u.name,
       o.total,
       i.price
FROM t_user u
LEFT JOIN t_order o
    ON u.id = o.user_id
LEFT JOIN t_order_item i
    ON o.id = i.order_id
    AND i.deleted = 0
WHERE o.total > 100

看起来更整洁了对吧？但问题是：AND i.deleted = 0 到底属于哪个 ON？原始写法把 AND 跟 ON 放一行，层级一眼就能看清。格式化后 AND 缩进在 ON 下，容易让人误以为它是 LEFT JOIN 的第二个条件而不是 JOIN 条件的延伸。

坑 2：子查询缩进导致括号看不清

原始写法靠 ( ) 对齐能快速配对：

SELECT * FROM t_user
WHERE id IN (
    SELECT user_id FROM t_order
    WHERE total > (SELECT AVG(total) FROM t_order)
)

格式化之后：

SELECT *
FROM t_user
WHERE id IN (
    SELECT user_id
    FROM t_order
    WHERE total > (
        SELECT AVG(total)
        FROM t_order
    )
)

括号层数多了之后，格式化会把括号对齐改成阶梯式，反而让你看不清哪对括号是闭包关系。复杂嵌套子查询（3 层以上）格式化后建议手动还原括号层级对齐。

坑 3：CASE WHEN 格式化后 ELSE 不在同一层级

SELECT
    CASE WHEN status = 1 THEN '正常'
         WHEN status = 0 THEN '禁用'
         ELSE '未知' END AS status_desc
FROM t_user

某些格式化工具会把 WHEN 的条件缩进改成比 CASE 多 2 个空格，ELSE 又缩回去——反而破坏了 CASE WHEN 的视觉对齐。好的 SQL 格式化器应该让 CASE/WHEN/ELSE/END 的关键字保持在同一列。

坑 4：格式化工具破坏了 SQL 注释和 Hint

Oracle 的 /*+ INDEX(t_user idx_user_name) */ Hint、MySQL 的 # 注释、内联的 -- 行注释——格式化时如果保留不当，要么注释被合并到上一行，要么 Hint 被拆成多行导致 Hint 失效。

-- 这个格式化后通常没问题
SELECT /*+ INDEX(t_user idx_user_name) */ * FROM t_user;

但某些格式化工具会把 Hint 里的空格替换掉（比如压缩成一个空格），Oracle 的 Hint 对内部空格敏感，会变成无效 Hint。

坑 5：MySQL 方言专有语法被误格式化

MySQL 的 ON DUPLICATE KEY UPDATE、SET @var = value、ENUM('a','b','c') 这些专有语法，某些格式化工具会按标准 SQL 拆行或加空格，导致执行失败。格式化前先确认目标方言，格式化后重点检查这几类语句。

正确使用方式

先确认方言差异：MySQL / Oracle / PostgreSQL / SQL Server 语法差异大。SQL 格式化工具按通用 SQL 规则排版，不做方言语法校验，偏差见坑 5 时仍要人工复核。
格式化后必复查复杂片段：JOIN 层级、CASE WHEN、嵌套子查询、Hint 注释这四类，格式化后必须快速扫一眼，觉得缩进怪就手动调。
生产 SQL 别格式化：发版前格式化 SQL 再对照差异，容易漏掉格式化引入的缩进/空格差异（某些 ORM 会缓存 SQL 字符串做 key，格式化后缓存 key 变了）。
字符串内容不归格式化管：格式化只调排版，不会碰引号里的内容。值本身含单引号时仍要自己转义（It's），否则拼进 SQL 就在引号处截断，报语法错误。批量拼 INSERT 时用 SQL 字符串转义工具处理，比手工数引号可靠。