派生表必须有别名，否则报错；不能引用外部列；嵌套时需每层别名唯一；通常物化影响性能，建议用CTE替代并EXPLAIN验证。
派生表必须有别名，否则会报错
SQL标准要求每个派生表（即SELECT子查询）在FROM子句中必须显式指定别名，否则绝大多数数据库（PostgreSQL、SQL Server、MySQL 8.0+、SQLite）都会报类似ERROR: subquery in FROM must have an alias或Every derived table must have its own alias的错误。
常见错误写法：SELECT * FROM (SELECT id, name FROM users WHERE active = 1) —— 缺少别名，直接报错。
正确写法是紧接在右括号后加一个合法标识符：
SELECT u.id, u.name FROM (SELECT id, name FROM users WHERE active = 1) AS u;
注意：AS关键字可省略（如(...) u），但别名本身不可省；别名不能是保留字（如order、group），否则需用双引号或方括号包裹（依数据库而定）。
派生表里不能直接引用外部查询的列
派生表是独立执行的子查询，作用域隔离，无法访问外层FROM或WHERE中的列。比如下面这段会失败：
SELECT o.order_id, d.total FROM orders o JOIN (SELECT SUM(amount) AS total FROM order_items WHERE order_id = o.order_id) AS d ON true;
o.order_id在子查询内部不可见 —— 这不是相关子查询，而是FROM里的非相关派生表。
解决方式只有两种：
- 把关联逻辑移到外层：先
JOIN基础表，再GROUP BY聚合 - 改用
LATERAL（PostgreSQL、SQL Server 2016+）或CROSS/OUTER APPLY（SQL Server）实现相关派生 - MySQL 8.0+ 可用
LATERAL，但语法仍较新，兼容性需验证
简单替代写法（通用）：SELECT o.order_id, COALESCE(SUM(oi.amount), 0) AS total FROM orders o LEFT JOIN order_items oi ON oi.order_id = o.order_id GROUP BY o.order_id。
嵌套派生表时注意括号层级和别名唯一性
多层嵌套时，每层括号都必须配对，且每层派生表都要有**互不冲突的别名**。例如：
SELECT t1.name, t2.avg_score FROM ( SELECT dept_id, AVG(score) AS avg_score FROM scores GROUP BY dept_id ) AS t2 JOIN ( SELECT id, name, dept_id FROM employees ) AS t1 ON t1.dept_id = t2.dept_id;
容易踩的坑：
- 漏写某一层的别名（比如只给外层派生表起了
t1，内层没起，就报错） - 两个派生表用了相同别名（如都叫
t），某些数据库会报table name specified more than once - 括号不匹配导致语法错误，尤其在复杂
UNION或带ORDER BY的子查询里（注意：ORDER BY在派生表内部无效，除非配合LIMIT或窗口函数）
性能影响：派生表通常物化，慎用于大表
多数数据库（如PostgreSQL、SQL Server）会将派生表作为临时结果集物化（materialize），意味着它会先完整执行子查询、生成中间结果，再参与后续JOIN或过滤。这对大表可能带来明显开销。
典型风险场景：
- 子查询无
WHERE条件，扫描全表（如(SELECT * FROM logs)） - 子查询含
ORDER BY + LIMIT但未被下推（某些旧版本优化器无法将外层WHERE下推进派生表） - 重复使用同一派生表多次（如在
SELECT和WHERE中各引用一次），可能触发多次执行
优化建议：
- 确保派生表子查询有高效索引支持的过滤条件
- 考虑用CTE（
WITH）替代——语义等价，但部分数据库（如PostgreSQL）会对CTE做更灵活的优化（尤其是MATERIALIZED/NOT MATERIALIZED提示） - 用
EXPLAIN查看执行计划，确认是否真的生成了临时表或是否走索引
真正麻烦的不是语法，而是你以为它“只是换个写法”，结果发现执行计划比直连表慢三倍。查之前先EXPLAIN。
