子查询必须显式指定别名，且外层所有字段引用须加该别名前缀；字段重命名、避免*、限定主表字段、where/having不可用select别名，均属硬性要求。
必须给子查询起别名，并在外层所有引用字段前加上该别名前缀——这不是可选项，是解析器硬性要求。
子查询必须带别名，且外层字段引用必须限定
MySQL 报 Every derived table must have its own alias，PostgreSQL 更进一步，连 FROM (SELECT ...) t 少个 AS 都可能失败。问题不在你漏写了什么，而是数据库根本不会尝试推导“这个子查询叫啥”，它只认显式声明的别名。
- 错误写法：
SELECT id FROM (SELECT id FROM users) WHERE id > 10—— 子查询没别名，MySQL 直接拒解析 - 正确写法：
SELECT t.id FROM (SELECT id FROM users) AS t WHERE t.id > 10—— 别名t必须出现在SELECT和WHERE中 - 别名要语义化：用
recent_orders比t1更易维护，也方便后续加 JOIN 或嵌套
多表 JOIN + 子查询时字段冲突最危险
当主表（如 orders）和子查询（如 SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id）都含 user_id，外层 SELECT user_id, c 必然报 Column 'user_id' in field list is ambiguous。这不是数据库“较真”，是它拒绝做任意选择。
- 解决只有两个字：限定。子查询起别名
AS stats，外层所有字段必须写成stats.user_id、stats.c - 主表字段也要写全：
orders.order_date，不能依赖ON条件就省略前缀 - 别在子查询里用
*：SELECT * FROM (SELECT u.id, o.amount FROM users u JOIN orders o)会把同名列直接平铺出来，加剧歧义
子查询内部字段也要重命名，避免层层传递歧义
如果子查询输出列名和外层表重复（比如都叫 id），即使加了别名，外层 SELECT t.id 仍可能被误读为外层表字段——尤其在三层以上嵌套或 CTE 场景中。
- 在子查询内就完成清洗：
(SELECT u.id AS user_id, o.id AS order_id FROM users u JOIN orders o) AS t - 外层直接用
t.user_id、t.order_id，彻底隔离基表字段名 - 视图或 CTE 同样适用：定义时用
AS显式声明字段名，后续调用不依赖原始表结构 - ORM 映射时尤其关键：没重命名就可能返回
id、users.id、orders.id三种不同键名，导致代码运行时报KeyError
WHERE 和 HAVING 里不能用 SELECT 别名
很多人写 SELECT u.name AS user_name FROM users u WHERE user_name = 'Alice'，结果报 Unknown column 'user_name' in 'where clause'。这是因为别名在 WHERE 阶段还不可见——SQL 执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。
-
WHERE只能引用原始字段或子查询输出列（带别名前缀），不能用SELECT里的别名 - 正确写法：
WHERE u.name = 'Alice'或WHERE t.user_name = 'Alice'（前提是t是子查询别名且user_name是其输出列） -
HAVING同理：它作用于分组后结果，只能用聚合函数或GROUP BY中明确写出的字段（带前缀）
最容易被忽略的是作用域分层：子查询的 AS 不会“透出”到上层，每一层的字段可见性都是封闭的。写完嵌套后，随手把光标停在任一字段上，问自己“这个字段此刻属于哪个别名？有没有被更外层同名字段覆盖？”——多数歧义错误，当场就能揪出来。
