只有相关子查询才能引用外层表字段，普通子查询和派生表均无法访问；相关子查询须用于where、having或select标量上下文，并显式关联外层表别名。
子查询里用不到外层表的字段？作用域搞错了
SQL嵌套查询中，SELECT 子句里引用外层表字段报错（比如 Unknown column 't1.name' in 'field list'），根本原因不是语法写错，而是子查询类型不支持跨作用域访问——只有相关子查询（correlated subquery）才能引用外层表，而普通子查询（uncorrelated）是独立执行的，压根看不到 t1。
- 相关子查询必须出现在
WHERE、HAVING或SELECT的标量上下文中，且内部需显式引用外部表别名（如t1.id） - 如果写成
FROM (SELECT ...)这种派生表（derived table），它就是独立作用域，t1.name在里面永远无效 - MySQL 8.0+ 和 PostgreSQL 支持在
LATERAL子查询中显式声明依赖，但多数旧版本只能靠相关子查询硬解
WHERE 中的子查询能用外层字段，但 SELECT 中容易翻车
WHERE 后跟相关子查询很常见，比如 WHERE id IN (SELECT user_id FROM logs WHERE logs.user_id = users.id)，这里 users.id 是合法的。但一旦把同样逻辑挪到 SELECT 列表里，就容易忽略“标量化”要求：
-
SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) AS order_cnt FROM users✅ 可行：子查询返回单值，且明确关联了users.id -
SELECT name, (SELECT order_id, created_at FROM orders WHERE orders.user_id = users.id) FROM users❌ 报错：子查询返回多列，不满足标量上下文 -
SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = wrong_alias.id) FROM users❌ 报错：别名wrong_alias根本不存在，外层表别名必须严格匹配
FROM 子句里的子查询（派生表）完全隔离
写成 FROM (SELECT ...) AS t2 的结构，相当于创建一张临时表，它和外层查询是两个独立执行单元，没有变量传递机制：
- 外层的
t1.name在FROM (SELECT ...)内部不可见，连AS t1都没意义 - 如果真需要关联，只能用
JOIN显式连接：FROM users t1 JOIN (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) t2 ON t1.id = t2.user_id - 某些人试图用
WHERE 1=1 AND t1.id = t2.user_id去“穿透”，没用——t1在括号内根本不可解析
MySQL 5.7 vs 8.0 在作用域处理上的细微差别
MySQL 5.7 对相关子查询的列解析相对宽松，有时允许模糊别名；但 8.0 强化了作用域检查，尤其在 GROUP BY 或窗口函数共存时更严格：
- 5.7 可能容忍
SELECT (SELECT name FROM t2 WHERE t2.id = t1.id) FROM t1，即使t2.name实际上未被t2选中（只因优化器提前终止） - 8.0 会直接报
Unknown column 't2.name' in 'field list'，因为子查询自身SELECT列表里没包含name - 使用
EXPLAIN FORMAT=TREE能看出子查询是否被标记为dependent subquery，这是判断是否真正相关的关键信号
外层字段能不能进子查询，不看位置，只看子查询是否被引擎识别为相关。手抖少打一个等号、别名拼错半个字母、或者误把 JOIN 逻辑塞进 FROM 子查询里——这些地方一卡，作用域就断了，而且错误提示往往不指明根源。
