子查询中用as定义的列别名仅在该子查询内有效，外部查询不可直接引用；若需在外层使用，必须为子查询指定表别名，并通过“表别名.列名”方式访问。

子查询里定义的别名在外部查不到

SQL嵌套查询中，子查询内部用 AS 定义的别名（比如 SELECT name AS user_name FROM users）只在该子查询范围内有效。外部查询不能直接引用这个 user_name，除非子查询本身被整体赋予一个表别名，并且列名通过“表别名.列名”方式访问。

常见错误现象：Unknown column 'user_name' in 'field list' —— 这说明你试图在外部 SELECT 或 WHERE 中直接用了子查询里的列别名，但没走正确的引用路径。

• 子查询的列别名不自动“透出”到外层，它只是用于当前子查询内部的列重命名
• 若想在外层使用，必须给子查询加表别名（如 (SELECT id, name AS user_name FROM users) AS u），再写 u.user_name
• 如果子查询是 FROM 子句中的派生表，它的列名对外可见性取决于是否显式命名或有默认名；未命名列在 MySQL 8.0+ 中可能报错，在旧版本中可能被忽略或取源名

WHERE 或 ORDER BY 引用子查询列时总报错

在外部查询的 WHERE、ORDER BY 或 SELECT 列表中，不能直接写子查询中定义的列别名（如 user_name），除非该子查询位于 FROM 子句且已绑定表别名。

典型错误场景：把子查询放在 SELECT 表达式里（即标量子查询），例如 SELECT (SELECT name FROM users WHERE id = 1) AS user_name, user_name FROM orders —— 后面的 user_name 会报错，因为标量子查询的别名不构成作用域上下文。

• 标量子查询（括号内单值）的 AS 别名仅用于结果列显示，不创建可引用的作用域
• ORDER BY 可以用列序号（如 ORDER BY 2）或外部 SELECT 中定义的别名，但不能跨层引用子查询内部别名
• MySQL 允许 ORDER BY 引用 SELECT 列表中的别名，PostgreSQL 和 SQL Server 默认不允许（需开启兼容模式或改写）

多层嵌套时别名容易撞车或覆盖

当嵌套超过两层（比如子查询里还有子查询），各层定义的相同列别名不会互相影响，但一旦在某一层用表别名 + 点号引用，就严格绑定到那一层的结构。容易误以为“最内层的 id 能被最外层直接叫出来”，其实不能。

例如：SELECT * FROM (SELECT * FROM (SELECT id, name FROM users) AS inner_t) AS outer_t，此时 outer_t.id 是合法的，但 inner_t.id 在最外层不可见 —— inner_t 的作用域只存在于它的直接父查询中。

• 每一级子查询的表别名只在其**直接上一级**查询中有效
• 列名解析优先匹配最近作用域：先找当前 FROM 中的表/别名，再找外层，但不会跳过一级去查更内层
• 避免用泛化列名（如 id、name）做别名，尤其在 JOIN 多表或嵌套深时，建议统一加前缀，如 u_id、u_name

用 CTE 替代深层嵌套能理清作用域

相比多层括号子查询，WITH 定义的公用表表达式（CTE）让别名作用域更清晰、可读性更强，而且支持递归和多次引用。

CTE 中定义的列名在后续主查询中可直接使用，无需点号前缀（只要不歧义）；多个 CTE 并列时，每个都有独立命名空间。

• CTE 的列名在 SELECT 主体中属于“第一层命名空间”，比子查询更宽松
• PostgreSQL 和 SQL Server 对 CTE 列名推导更智能；MySQL 8.0+ 支持，但要求所有列显式命名（不能依赖源表名）
• 注意：CTE 不是视图，不缓存结果，每次引用都会重新执行 —— 深层嵌套改写为 CTE 后，性能未必提升，甚至可能下降

别名作用域不是语法糖，而是 SQL 执行计划生成的前提。写嵌套查询时，每加一层括号，就新增一层隔离边界；越往里定义的东西，越难被外面伸手拿到。真要跨层传数据，老实用表别名 + 点号，或者换 CTE 拆开写。