相关子查询才能引用外层字段，普通子查询、派生表或CTE均不可；报“Unknown column 't1.name' in 'field list'”说明误将非相关子查询当作可穿透作用域的结构，需确认其位于WHERE/HAVING/标量子查询位置并显式使用外层表别名。
相关子查询里引用外层字段报 Unknown column
只有相关子查询才能访问外层表字段，普通子查询、派生表（FROM (SELECT ...)）、CTE 都不行。报 Unknown column 't1.name' in 'field list' 说明你误把非相关子查询当成了能“穿透作用域”的结构。
- 检查子查询是否出现在
WHERE、HAVING或SELECT的标量位置（即必须返回单值） - 确认外层表别名在子查询中被显式引用，比如
t1.id，而不是只写id - 避免在
FROM子句里写(SELECT ... FROM orders WHERE user_id = t1.id) AS t2—— 这里的t1.id在括号内根本不可解析 - MySQL 8.0+ 和 PostgreSQL 可用
LATERAL显式声明依赖，但多数旧环境只能靠标准相关子查询硬解
SQL Server 中子查询访问不了 @variable
@variable 是批处理级变量，子查询执行时处于独立上下文，不继承父作用域。报错 Must declare the scalar variable "@xxx" 不是语法错，是设计如此。
- 变量只能作为常量“带入”子查询的
WHERE条件，例如WHERE id = @user_id，但不能在子查询内部重新声明或赋值 - 三层以上嵌套时，某些 SQL Server 版本会直接拒绝解析变量，建议提前用临时表或 CTE 拆解
- 若变量为
NULL，= @var判断会因三值逻辑失效，应改用IS NULL或COALESCE(@var, -1) - 真正需要“参数化子查询”的场景，优先用
JOIN或APPLY替代，语义更清晰，也绕过作用域幻觉
FROM 子句中的派生表无法被外层 WHERE 引用
FROM (SELECT ...) 创建的是完全隔离的临时结果集，它和外层查询之间没有变量传递机制。你在 WHERE 里写 T2.avg_salary = ... 会报错，因为 T2 的作用域仅限于 FROM 子句本身。
-
WITH定义的 CTE 名称全局可见，而FROM (...) AS T2的T2只在当前查询层级有效 - 想复用聚合结果，要么提成 CTE，要么用
JOIN显式连接：例如FROM users u JOIN (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) o ON u.id = o.user_id - 别试图用
WHERE 1=1 AND u.id = o.user_id“绕开”，o在WHERE外部根本未定义 - MySQL 5.7 不支持视图合并，如果把这类逻辑封装成视图，
WHERE条件可能完全下推失败，导致全量计算
嵌套过深时列名解析突然失效
MySQL 查找列名只认「当前层级 + 上一层」，跨两层以上就会丢掉引用。比如三层嵌套中，最内层想用最外层的 users.id，不加别名或路径前缀就必然报 Unknown column。
- 所有跨层级引用的字段，必须带明确表别名，如
u.name、o.order_id - 避免外层和子查询使用同名列却不加前缀，例如外层
SELECT id，子查询又SELECT id，再在外层WHERE id = (subquery)—— 歧义必崩 - 用
EXPLAIN看执行计划时，如果rows突然暴涨，很可能是某层子查询因列解析失败退化为全表扫描 - 嵌套超 3 层后，优化器常放弃精确代价估算，字段别名和 NULL 传播也容易失控，拆成 CTE 或临时表反而更稳
实际写嵌套查询时，最容易被忽略的不是语法，而是“哪一层能看到哪一层”。作用域不是隐式连通的管道，而是有明确边界的盒子。每次加一层 SELECT，就得重新确认变量、别名、列名的可见边界——漏掉一次，就是一条查不到数据或直接报错的 SQL。
