缩进是SQL中识别嵌套层级、作用域和执行顺序的唯一视觉锚点；缺乏一致缩进会导致WHERE条件作用层、ORDER BY生效对象难以判断，引发Column not found、性能雪崩、NOT IN空结果等隐蔽逻辑错误。
缩进本身不改变SQL语义，但它是人眼识别嵌套层级、作用域和执行顺序的唯一视觉锚点；缺乏一致缩进时，WHERE 条件实际作用在哪一层、ORDER BY 是对临时结果还是原始表生效，几乎无法靠肉眼判断。
子查询别名覆盖导致 Column not found 的典型现场
当多层嵌套中未显式声明别名，或别名重复，外层引用字段时容易报 Unknown column 'x' in 'field list'。这不是语法错，而是作用域混乱的直接结果。
- 子查询里
SELECT user_id AS id，外层又写SELECT id FROM (...) t，两个id冲突，后定义的会覆盖前一个 -
FROM (SELECT u.id, u.name FROM users u) t JOIN (SELECT o.user_id FROM orders o) o2 ON t.id = o2.user_id—— 这里t.id看似安全，但如果内层users u没选id，只写了SELECT u.name，错误直到执行才暴露 - 解决办法不是加更多括号，而是每层子查询都用唯一别名 + 显式列出字段，例如
(SELECT u.id AS user_id, u.name AS user_name FROM users u) users_sub
相关子查询（correlated subquery）缩进错位引发性能雪崩
相关子查询依赖外层值，每次外层行迭代都要重执行一次。缩进若没体现“依赖关系”，很容易误以为它是独立子查询而忽略其放大效应。
- 写成这样：
SELECT name FROM users WHERE EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id)，如果orders.user_id没索引，EXISTS就退化为对 orders 表的逐行扫描 - 缩进若把
WHERE orders.user_id = users.id和外层对齐，就掩盖了它其实是“被驱动”的关键条件 - 正确缩进应让依赖字段明显缩进一级，例如：
SELECT name FROM users WHERE EXISTS ( SELECT 1 FROM orders WHERE orders.user_id = users.id -- 这一行明显向内缩进，提示它是绑定外层的 )
NOT IN + NULL 导致空结果却查不出问题，缩进暴露逻辑断层
NOT IN (SELECT id FROM users) 返回空，往往不是数据真为空，而是子查询里混入了 NULL。缩进混乱会让这个子查询看起来像“已过滤干净”，实则没做任何非空校验。
- 错误写法：
SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users)—— 如果users.id含NULL，整个条件判为UNKNOWN，所有行被过滤 - 缩进若把子查询单独成块并加注释，就容易补上
WHERE id IS NOT NULL - 更稳妥的是改用
NOT EXISTS，但前提是缩进能让人一眼看出“这里必须关联”：NOT EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id)
缩进不是风格偏好，是防止把 WHERE 写错层、把 GROUP BY 挂错表、把 LIMIT 放在不该放的位置的最低成本防线。真正难排查的逻辑漏洞，往往藏在看似“格式正确”的缩进间隙里。
