SQL Server子查询无法访问外层@variable，因变量作用域限于当前批处理，子查询运行在独立上下文；唯一合法方式是将变量值作为常量显式写入子查询WHERE条件，如WHERE id = @user_id。
SQL嵌套查询里用不了外层声明的 @variable，这不是写错了，是 SQL Server（以及多数数据库）的设计限制——子查询执行时根本不在同一个作用域里。
SQL Server 中 @variable 在子查询里报 Must declare the scalar variable "@xxx"
这个错误不是语法问题，而是 T-SQL 的作用域规则：批处理级变量 @variable 只在当前 BATCH 有效，而子查询（包括 IN、EXISTS、标量子查询）会启动独立的执行上下文，不继承父作用域。
- 哪怕你在
SELECT前刚DECLARE @user_id INT = 123，只要在子查询的WHERE或SELECT列表里直接写@user_id，就必然报错 - CTE、视图、存储过程内部的子查询同样无法访问外部变量，它们都是独立求值单元
- 唯一能“带进去”的方式，是把变量值作为常量参与子查询的条件表达式，例如：
WHERE id = @user_id—— 这个@user_id是由外层解析后传入的，不是子查询自己去“读取”的 - 如果变量为
NULL，= @user_id会因三值逻辑返回UNKNOWN，应改用IS NULL或COALESCE(@user_id, -1)
MySQL/PostgreSQL 中子查询无法引用外层字段的常见误判
报 Unknown column 't1.name' in 'field list'，往往不是字段不存在，而是你误把普通子查询当成了相关子查询。只有出现在 WHERE、HAVING 或标量位置（即必须返回单值）的子查询，才允许显式引用外层表别名。
-
FROM (SELECT * FROM orders WHERE user_id = t1.id) AS t2—— 这种写法非法，t1.id在括号内完全不可见 - 正确做法是让子查询成为相关子查询：
SELECT name FROM users t1 WHERE EXISTS (SELECT 1 FROM orders t2 WHERE t2.user_id = t1.id) - MySQL 查找列名只认「当前层级 + 上一层」，跨三层嵌套时，最内层想用最外层的
users.id，必须显式写成t1.id，不能只写id - 别名冲突很隐蔽：外层用
u，子查询又定义FROM users AS u，那子查询里的u.id指的是它自己的u，不是外层的
替代方案：用 JOIN 或 LATERAL 显式建模依赖关系
硬扛变量传递或作用域穿透，不如换结构。多数需要“用外部值驱动子查询”的场景，语义更清晰、执行更可控的方式是显式连接。
- 用
JOIN替代相关子查询：SELECT u.* FROM users u JOIN (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id) o ON u.id = o.user_id - PostgreSQL 9.3+ 支持
LATERAL，可显式声明派生表依赖外层：SELECT u.name, o.c FROM users u, LATERAL (SELECT COUNT(*) c FROM orders WHERE user_id = u.id) o - SQL Server 推荐用
APPLY（CROSS APPLY/OUTER APPLY）替代标量子查询，避免三层以上嵌套导致的变量解析失败 - 若逻辑复杂到需要多次复用中间结果，优先拆成临时表或 CTE，而不是靠多层嵌套“一气呵成”
真正难处理的不是语法怎么写，而是哪一层该负责哪部分计算——外层查 ID，子查询查状态，应用层做映射，这种分工一旦模糊，作用域问题就会反复出现。
