子查询在FROM子句中必须加别名，否则主流数据库解析阶段直接报错；别名是派生表的唯一标识，用于列绑定、JOIN匹配和作用域划分，缺失将导致歧义或静默错误。
FROM子句里的子查询不加别名会直接报错
这不是风格问题，是SQL标准强制要求的语法底线——不加别名，主流数据库一律拒绝执行。MySQL 报 Every derived table must have its own alias，PostgreSQL 报 subquery in FROM must have an alias，SQL Server、Oracle、Spark SQL 同样严格遵循。错误发生在解析阶段，连执行计划都不会生成。
- ❌ 错误写法：
SELECT * FROM (SELECT user_id, COUNT(*) FROM logs GROUP BY user_id) - ✅ 正确写法：
SELECT * FROM (SELECT user_id, COUNT(*) FROM logs GROUP BY user_id) AS user_activity - 别名必须紧跟右括号后，
AS可省略（如) user_activity），但显式写出更安全，避免空格歧义
别名是派生表在SQL语义层的唯一身份标识
FROM 子句中每个数据源（物理表、视图、表函数、子查询）都必须能被唯一引用。子查询返回的是一个临时结果集，没有真实表名，数据库解析器靠别名把它“注册”为一张逻辑表，才能做列绑定、JOIN 条件匹配、作用域划分。
- 没别名时，
ON u.id = ???里的右侧字段根本无法定位来源 - 两个子查询 JOIN 时，若都叫
t，ON t1.x = t2.y就无从成立——别名是作用域锚点，不是装饰 - 别名不能是保留字（如
order、group、user），否则需用反引号（MySQL）或双引号（PostgreSQL/SQL Server）包裹，但建议直接避开
常见别名写法陷阱与兼容性风险
位置错、命名糊、复用混，都会导致跨引擎行为不一致或静默错误。尤其在迁移或混合使用 MySQL/PostgreSQL 时，看似能跑通的写法可能在另一环境崩掉。
- ❌ 错误：把
AS stats写进子查询内部 ——(SELECT id FROM t AS stats)→ 这是给字段起别名，不是表别名 - ❌ 错误：别名带空格或中文 ——
) AS my table或) AS 用户统计→ 必须加引号，且多数驱动不推荐 - ❌ 错误：外层和子查询共用别名 ——
FROM users u JOIN (SELECT * FROM users) u ON u.id = u.user_id→ 列引用完全歧义，PostgreSQL 直接报错 - ✅ 推荐：小写+下划线，如
user_summary、latest_order，一眼可读，跨引擎零风险
别名缺失引发的列歧义比报错更危险
有些旧版 MySQL（如 5.6）对无别名子查询容忍度高，但代价是列解析不可控：当子查询输出列与外部表同名，又没加前缀时，MySQL 可能取最后一个同名列值，而 PostgreSQL 会直接报 column reference "id" is ambiguous。这种差异常在上线后暴露，排查成本极高。
- 子查询字段应显式命名，避免依赖
SELECT *——SELECT u.id AS user_id比SELECT u.*更健壮 - JOIN 多张表 + 子查询时，所有列引用必须带前缀，哪怕只用一次 ——
u.name、p.amount、stats.total - CTE（
WITH）虽不强制AS，但 CTE 名本身也承担别名职责，同样不能重名、不能是保留字
别名不是写完就完的事。它一旦出现，就必须全程一致；漏一个前缀、拼错一个字母，错误可能延迟到运行时才暴露，而且报错位置往往和实际出错点隔了好几行。
