子查询中用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 拆开写。
