子查询不能自动访问外层变量，仅where/having、select列表标量子查询及lateral/apply才支持相关子查询；跨层引用需用cte、join或逐层传参。
子查询里用不到外层变量？先确认是不是相关子查询
SQL 中的变量（包括参数和表别名）不能跨作用域自动穿透，这是设计使然，不是 bug。报 Must declare the scalar variable "@xxx" 或 Unknown column 't1.name' in 'field list'，大概率是因为你把普通子查询当成了相关子查询。
只有出现在以下三处的子查询才被识别为“相关”：
-
WHERE或HAVING条件中（如WHERE id IN (SELECT ... WHERE t1.status = status)） -
SELECT列表里的标量子查询（返回单值，如(SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id)） -
FROM子句中显式使用LATERAL（PostgreSQL/Oracle）或APPLY（SQL Server）——但 MySQL 不支持
写在 FROM (SELECT ...) 里的子查询是完全隔离的，哪怕里面写了 @status 或 t1.id，都会直接报错或解析为 NULL。
SQL Server 中 @variable 在嵌套子查询里失效怎么办
SQL Server 的批处理级变量 @variable 不会自动传递进子查询执行上下文。即使你在主查询里声明了 @status，三层嵌套中的最内层子查询也看不到它——这不是缓存问题，是作用域隔离机制。
常见错误写法：
DECLARE @status INT = 1;
SELECT * FROM orders
WHERE order_id IN (
SELECT order_id FROM order_items
WHERE item_id IN (
SELECT item_id FROM items WHERE category = @status -- ✅ 这里能用
)
);
看起来能用？其实只是“碰巧”没报错，因为最内层仍处于同一编译批次；但一旦拆成独立存储过程、或升级到 SQL Server 2022+ 的严格模式，就可能失败。真正稳妥的做法是逐层“带入”：
- 每一层子查询涉及的参数，都需声明对应局部变量，且类型、长度、NULL 性必须完全一致
- 例如：外层用
@status（INT），内层就得用@status_inner INT = @status，不能用@status_inner VARCHAR(10) - 三层嵌套时，第二层和第三层都要各自声明并赋值，漏一层就可能触发参数嗅探或类型隐式转换
MySQL / PostgreSQL 多层嵌套列名突然找不到？检查作用域深度限制
MySQL 5.7 只允许列名解析“当前层 + 上一层”，跨两层以上（比如外层 A → 中层 B → 内层 C）时，C 层访问 A 的字段会直接报 Unknown column。PostgreSQL 和 SQL Server 稍宽松，但也不保证稳定。
典型翻车场景：
SELECT u.name,
(SELECT COUNT(*)
FROM (SELECT o.order_id
FROM orders o
WHERE o.user_id = u.id) AS tmp -- ✅ 这里 u.id 可见（上一层）
WHERE tmp.order_id IN (
SELECT oi.order_id
FROM order_items oi
WHERE oi.order_id = tmp.order_id -- ❌ 这里 tmp.order_id 是上一层，但 u.id 已不可见
)
) AS cnt
FROM users u;
解决办法不是加更多别名，而是切断嵌套链：
- 把中间聚合或过滤提前抽成 CTE（MySQL 8.0+ / PostgreSQL / SQL Server）
- 用
JOIN替代多层IN，例如把最内层order_items直接和users关联 - 避免在
FROM子句里再嵌套WHERE引用外层字段——这种写法在多数引擎里语法就不合法
别硬扛嵌套，用 CTE 或临时表拆解更可靠
三层以上嵌套子查询不是“写法技巧问题”，是执行模型瓶颈：优化器很难为每层单独估算行数，容易导致计划固化、临时表膨胀、Using temporary; Using filesort 频发。
实操建议优先级：
- 能用
JOIN代替IN/EXISTS的，一律改写——语义等价、作用域清晰、还能利用统计信息重选连接算法 - 需要复用中间结果（如部门平均销售额）的，用 CTE：
WITH dept_avg AS (SELECT dept_id, AVG(salary) avg_sal FROM emp GROUP BY dept_id)，然后JOIN引用 - MySQL 5.7 或需强控制执行顺序的，建
TEMPORARY TABLE并加索引，比嵌套子查询快一个数量级 - 涉及窗口函数的逻辑（如“每个用户订单金额占比”），直接用
SUM() OVER (PARTITION BY ...)，彻底绕过标量子查询的 N×M 扫描
复杂点在于：CTE 和临时表不是“语法糖”，它们改变了数据生命周期和优化器可见性。一旦用了，就要同步检查索引覆盖、统计信息更新频率、以及是否引入了意外的 NULL 行为——尤其是 LEFT JOIN 后聚合结果与原标量子查询的语义对齐。
