嵌套查询默认无法访问外层列，需通过相关子查询显式关联；禁用内外层同名别名，标量子查询须确保单行单列，深层嵌套应改用cte或临时表提升可维护性与执行效率。
WHERE 子句里引用了外层查询的列，但数据库报 Unknown column
这是最典型的作用域错误：嵌套查询（子查询）默认无法直接访问外层查询的列，除非该列被明确暴露为相关子查询（correlated subquery）的一部分。MySQL、PostgreSQL 和 SQL Server 都会拒绝未声明的跨层引用。
常见现象是执行时报错类似：Unknown column 't1.name' in 'where clause'，而 t1 是外层表别名，出现在子查询的 WHERE 中却未加限定或未形成关联。
- 确认子查询是否**有意依赖外层**：如果是，必须让子查询“看到”外层列——即把外层列作为条件传入，例如
WHERE t2.user_id = t1.id - 避免在子查询的
SELECT或FROM中直接写t1.xxx；它只能出现在子查询的WHERE（且需与外层有连接条件）或作为EXISTS的关联谓词 - PostgreSQL 对作用域更严格，甚至不允许在子查询的
ORDER BY中引用外层列；MySQL 8.0+ 在某些场景下会隐式提升，但不可依赖
子查询用了和外层一样的表别名，结果查出意外的空集或重复数据
别名冲突不会报错，但会导致语义歧义。比如外层用 FROM users AS u，子查询又写 SELECT * FROM users AS u，那么子查询里的 u.id 指的是子查询内部的 u，而非外层的。
这种问题在 IN、= ANY 或标量子查询中尤其隐蔽，表面语法合法，逻辑却完全偏离预期。
- 子查询内**禁用与外层相同的别名**；建议加前缀，如外层用
u，子查询用u2或sub_u - 在子查询的
SELECT列表中，如果要返回外层字段，必须显式来自外层上下文（即不写在子查询里），或通过JOIN/EXISTS关联后带出 - 使用
EXPLAIN或执行计划查看实际扫描的表和别名绑定关系，比肉眼检查更可靠
标量子查询（SELECT 单值）里用了 GROUP BY，却提示 Invalid use of group function
标量子查询要求返回**至多一行一列**，但若内部写了 GROUP BY 或聚合函数（如 COUNT(*)）而没配合 WHERE 收敛范围，数据库可能因无法确定“该取哪组结果”而拒绝执行——尤其当外层有多行时，每行触发一次子查询，每次又产生多行聚合中间结果。
- 标量子查询中，聚合必须搭配能唯一确定单行的条件，例如：
(SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) - 避免在标量子查询里写无关联条件的
GROUP BY；那不是标量，是行集合 - 如果真需要分组统计再关联，改用
LATERAL JOIN（PostgreSQL / PostgreSQL 12+）或派生表 +JOIN，而不是硬塞进括号里
嵌套过深（3 层以上）导致可读性崩坏和优化器放弃生成有效执行计划
不是语法错误，却是实际开发中最常被忽略的“作用域隐性失效”：查询层级越多，列来源越难追溯，优化器也越可能退化为嵌套循环或临时表全扫。SQL Server 可能静默截断嵌套深度；MySQL 8.0 对 CTE 更友好，但老式括号嵌套仍受限。
- 超过 2 层嵌套时，优先拆成带
WITH的 CTE，每个 CTE 有自己的命名空间，作用域清晰可查 - 用 CTE 替代子查询时，注意 PostgreSQL 要求所有 CTE 必须被主查询引用，否则报错
relation does not exist - MySQL 5.7 不支持 CTE，此时可用临时表（
CREATE TEMPORARY TABLE）缓存中间结果，显式控制作用域边界
别名和嵌套层次不是语法装饰，是作用域的显式契约。少一层嵌套、多一个前缀、换一种写法，有时比查文档更快定位问题。
