派生表必须加别名是SQL语法硬性要求，所有主流数据库均强制执行；别名是解析器注册临时结果集元数据、绑定列引用及支持JOIN的必要标识，缺之则无法通过语法解析。
派生表不加别名直接报错是语法硬性要求
不是风格建议，也不是兼容性考虑——所有主流数据库（MySQL 8.0+、PostgreSQL、SQL Server、Oracle）在解析 FROM 子句中的子查询时，都强制要求必须带别名。不加就拒绝执行，错误信息非常明确：Every derived table must have its own alias（MySQL）、subquery in FROM must have an alias（PostgreSQL）。这是因为 SQL 解析器需要一个合法标识符来注册这个临时结果集的元数据上下文，没有别名就无法绑定列引用、无法参与 JOIN、甚至无法完成语法树构建。
别名是派生表对外暴露字段的唯一入口
派生表是一个独立作用域，它的列对外不可见，除非通过别名显式引用。比如：
SELECT id, name FROM (SELECT user_id AS id, username AS name FROM users WHERE active = 1) AS u;
这里外层能用 u.id 和 u.name，是因为 u 是唯一可寻址的“表名”。如果漏掉 AS u，即使子查询内部重命名了字段，外层也根本拿不到这些列——解析器连这张“临时表”叫什么都不认识，更别说找它的字段了。
- 子查询内部的
AS（如user_id AS id）只影响该子查询输出列名，不解决外部引用问题 - 外层
SELECT中若出现未加前缀的id，且存在其他同名字段（如主表也有id），立刻触发Column 'id' in field list is ambiguous - JOIN 派生表时，
ON条件里所有字段都必须带别名前缀，否则解析失败
别名冲突和保留字陷阱比想象中常见
别名看似随便起，但实际踩坑集中在两个地方：
-
order、group、user、index这类词哪怕加反引号，在跨库迁移或嵌套 CTE 场景下仍可能引发隐性解析异常，建议一律避开 - 别名和外部表名重复会导致字段解析歧义，例如
FROM users u JOIN (SELECT * FROM users) u ON ...—— 两个u让解析器无法区分作用域 - 别名不能是空字符串，也不能含空格或特殊符号（除非用双引号/反引号包裹，但不推荐）
最稳妥的做法是：用小写字母 + 下划线，语义清晰，如 active_users、order_summary、user_stats。
CTE 和派生表别名机制本质不同
有人以为 WITH active_users AS (SELECT ...) 可以替代 FROM (SELECT ...) AS active_users，其实二者别名角色完全不同：
-
WITH的active_users是 CTE 名，属于命名结果集，本身已是可引用对象，不需要额外AS - 而
FROM中的子查询是匿名临时表，AS是唯一赋予它身份的操作，缺一不可 - 混用时注意：CTE 内部再嵌套派生表，那个子查询依然要单独加别名
别名这件事，看起来只是多打几个字符，但它是 SQL 执行顺序（FROM → WHERE → SELECT）中，让列绑定和作用域划分得以成立的底层锚点。漏掉它，不是“查不到数据”，而是“连解析都过不去”。
