派生表必须有别名，否则报错；sql标准要求from子句中的子查询（即派生表）必须显式指定别名，mysql、postgresql、sql server等均强制执行，缺别名会触发类似“every derived table must have its own alias”的错误。
派生表必须有别名，否则报错
SQL标准要求FROM子句里的子查询（即派生表）必须显式指定别名，否则几乎所有数据库都会报类似 ERROR: subquery in FROM must have an alias 的错误。MySQL、PostgreSQL、SQL Server 都强制这一规则，哪怕只是临时用一下。
- ✅ 正确写法：
SELECT * FROM (SELECT id, name FROM users WHERE active = 1) AS active_users - ❌ 错误写法：
SELECT * FROM (SELECT id, name FROM users WHERE active = 1)（缺别名，直接报错） - 别名可以省略
AS关键字，(...) t和(...) AS t效果一样
派生表里不能直接引用外层查询的列
派生表是独立执行的子查询，作用域隔离——它看不到外部 SELECT 或 WHERE 中的列。常见误区是想在子查询里用外层表字段做过滤，比如试图写 (SELECT * FROM orders WHERE user_id = u.id) 放进 FROM，这会报 column u.id does not exist。
- 如果需要关联，得用 JOIN：先定义派生表，再用
ON连接外层表 - 或者改用 LATERAL（PostgreSQL）或 APPLY（SQL Server）这类支持相关子查询的语法
- MySQL 8.0+ 支持 LATERAL，但需明确写出关键字，不能省略
嵌套太深或数据量大时性能容易掉坑
派生表会物化（materialize）结果集，尤其在 PostgreSQL 或 SQL Server 中，可能生成中间临时结果，导致内存占用高、执行计划变差。不是所有场景都适合用派生表替代 JOIN 或 CTE。
- 简单过滤+投影（如
SELECT a, b FROM (SELECT *, ROW_NUMBER() OVER(...) rn FROM t) WHERE rn = 1）通常没问题 - 若派生表含聚合、窗口函数或大表扫描，先看执行计划里的
Materialize节点是否成为瓶颈 - 等价逻辑能用 CTE 实现时，CTE 在多数引擎里更易优化（尤其是 PostgreSQL），但注意 CTE 不是“视图”，仍可能重复执行
不同数据库对列名推导的支持不一致
派生表的列名来自子查询的 SELECT 列，但规则不统一。比如 SELECT x+1 FROM t 在 PostgreSQL 中默认列名为 ?column?，必须用别名；而 MySQL 会尝试推导为 x+1，但不可靠。
- 务必为派生表中的表达式列显式命名：
SELECT x+1 AS new_x FROM t - 否则外部查询引用时会出错，比如
SELECT new_x FROM (SELECT x+1 FROM t) AS t2在 PostgreSQL 中直接失败 - SQL Server 对无名列表达式更严格，连
SELECT 1都必须写成SELECT 1 AS c
实际写的时候，别图省事跳过别名和列名——这两处出错最频繁，且错误信息往往不提示根本原因。
