子查询在from中无法引用外层字段，因作用域隔离；正确做法是将条件移至on或where，或改用标量子查询、lateral（postgresql/mysql 8.0+）等支持相关引用的上下文。
子查询在FROM里根本看不到外层字段
这是最常见的误用场景。写成 SELECT * FROM users u JOIN (SELECT * FROM orders WHERE user_id = u.id) AS o ON 1=1，MySQL 或 PostgreSQL 会直接报 Unknown column 'u.id' in 'where clause'。因为 FROM 子句里的子查询（即派生表）是完全独立的作用域，它不继承外层任何别名或字段。括号一包，就自成世界。
解决办法不是“怎么让它看见”，而是“别放那儿”：
- 把条件挪到
ON或WHERE外层：比如JOIN orders o ON o.user_id = u.id - 若逻辑复杂必须用子查询，改放到
SELECT或WHERE的标量位置，例如(SELECT COUNT(*) FROM orders WHERE user_id = u.id) - MySQL 8.0+ / PostgreSQL 可用
LATERAL显式声明依赖，但得重写语法：JOIN LATERAL (SELECT ...) AS o ON true，不是所有环境都支持
相关子查询能引用外层字段，但只限三个位置
只有出现在 WHERE、HAVING 或 SELECT 列表达式（即标量上下文）里的子查询，才被数据库识别为“相关子查询”，才允许引用外层字段。比如：
SELECT u.name, (SELECT MAX(created_at) FROM orders o WHERE o.user_id = u.id) AS last_order FROM users u WHERE u.id IN ( SELECT user_id FROM orders WHERE status = 'paid' AND user_id = u.id );
注意关键点：
- 外层别名必须显式写出：
u.id，不能只写id（否则可能匹配子查询内部同名列） - 子查询返回必须是单值（标量），否则放在
SELECT列里会报错 -
HAVING里只能引用本层GROUP BY字段或本层聚合函数，不能引用外层聚合别名
嵌套太深时字段解析直接失效
MySQL 查找列名只认「当前层级 + 上一层」。三层嵌套时，最内层想用最外层的 users.id，不加别名或路径前缀就必然报 Unknown column。这不是 bug，是 SQL 标准规定的作用域隔离机制。
典型陷阱：
- 子查询用了和外层一样的表别名（如都叫
u），结果u.id指的是子查询自己FROM users AS u的那一份，不是外层的 - 自连接场景更危险：
users u1 JOIN users u2必须区分，否则字段引用全乱 - 执行前务必看
EXPLAIN，确认扫描的是否是预期的表和索引——别名混淆会让执行计划指向错误对象
变量、CTE、视图都不能穿透子查询作用域
@user_id 这种变量在子查询里直接不可见，报 Must declare the scalar variable 是设计如此，不是漏写了 DECLARE。CTE 名称虽全局可见，但它定义的结果集仍是静态快照，子查询无法“动态传参”进去。
真正需要参数化行为时，优先考虑：
- 用
JOIN替代子查询：语义清晰，优化器友好，索引通常可用 - 提前固化中间结果：用
WITH或派生表把聚合/过滤结果先算出来，再关联 - 避免三层以上嵌套：
SELECT (SELECT (SELECT ))不仅难读，优化器大概率放弃重写，性能雪崩
最容易被忽略的是：子查询里字段引用看似合法，但执行计划可能已悄悄走全表扫——作用域问题常和索引失效叠加，排查时得分开验证。
