PostgreSQL 16中派生表默认不物化、不缓存，必须加别名且不可为保留字；不支持引用外层字段，需用LATERAL实现关联；优化器优先合并简单派生表以复用索引，含GROUP BY、ORDER BY等则触发物化。
PostgreSQL 16 中的派生表（FROM (SELECT ...)）默认不物化、不缓存，但也不自动优化——它既不会像 CTE 那样被重用，也不会像普通表那样走索引。能否快，全看你怎么写、怎么查、有没有索引支撑。
派生表必须加别名，且别名不能是保留字
PostgreSQL 强制要求每个 FROM 子句里的子查询带别名，否则报错：ERROR: subquery in FROM must have an alias。别名需合法，不能是 order、user、group 这类保留字，否则得用双引号包住：
SELECT * FROM (SELECT id, name FROM users WHERE active) AS "user";
常见踩坑点：
- 漏写
AS或别名（哪怕只差一个空格，如) u写成)u，某些客户端会静默失败） - 别名和外层表名冲突（比如外层有
users u，派生表又叫u，虽语法允许但极易引发列歧义） - 在同一个查询中重复使用同一别名（如两次
(SELECT ...) AS dt），PostgreSQL 不报错但行为未定义，建议用不同名或改用 CTE
派生表无法引用外层字段，LATERAL 才行
这是最常误踩的逻辑陷阱：FROM (SELECT * FROM orders WHERE user_id = users.id) AS o 在 PostgreSQL 中直接报错 ERROR: invalid reference to FROM-clause entry。因为派生表作用域完全独立，users.id 对它不可见。
如果你真需要“每行触发一次子查询”，必须显式改用 LATERAL：
SELECT u.name, latest.amount FROM users u LEFT JOIN LATERAL ( SELECT amount FROM orders o WHERE o.user_id = u.id ORDER BY o.created_at DESC LIMIT 1 ) latest ON true;
关键区别：
-
LATERAL是执行模型切换开关，不是可选修饰符；漏写就报错 -
JOIN LATERAL丢数据（左表无匹配时整行消失），LEFT JOIN LATERAL才保左表完整 - 性能上，LATERAL 是 N 次子查询执行，务必确保
orders(user_id, created_at)有复合索引，否则 10 万用户 = 10 万次全表扫描
避免物化开销：优先让优化器“合并”而非生成临时结果
PostgreSQL 16 默认尝试将简单派生表“合并”（merge）进外层查询，等价于直接 JOIN 原表——这能复用原表索引、下推条件、避免中间结果集。但合并有硬性前提：
- 子查询不含
GROUP BY、DISTINCT、LIMIT、ORDER BY（除非外层也排序） - 不含聚合函数（
COUNT()、MAX()等） - 子查询只查单表，且外层
FROM中只有该派生表或简单表
例如这个能合并：
SELECT u.name, o.total FROM users u JOIN (SELECT user_id, SUM(amount) AS total FROM orders WHERE status = 'paid') AS o ON u.id = o.user_id WHERE u.created_at > '2025-01-01';
但如果把 SUM() 换成 SELECT * 或加个 ORDER BY user_id，优化器大概率放弃合并，转而物化为无索引临时结果——这时 EXPLAIN 里会出现 Materialize 节点，且后续 JOIN 条件无法下推。
字段重命名与列歧义必须显式处理
派生表里若多个源列同名（比如两个 SELECT id FROM t1 和 SELECT id FROM t2 UNION ALL 后没重命名），外层 SELECT * 会报错 column reference "id" is ambiguous。
解决方案只有两个：
- 在派生表内部用
AS显式重命名冲突列：SELECT id AS order_id, user_id AS buyer_id FROM orders - 外层引用时加别名前缀：
o.id, u.id，但前提是派生表和外层表都起了别名
另一个易忽略点：WHERE 中不能直接用派生表 SELECT 阶段定义的别名做函数计算，比如：
SELECT * FROM (SELECT created_at AS log_time FROM logs) AS l WHERE EXTRACT(YEAR FROM l.log_time) = 2025; -- ✅ 可行（PostgreSQL 允许） -- 但下面这句在部分版本会失败： WHERE YEAR(l.log_time) = 2025; -- ❌ YEAR() 不是 PostgreSQL 内置函数
更稳妥的做法是把时间过滤下推到派生表内：SELECT created_at FROM logs WHERE created_at >= '2025-01-01' AND created_at ，减少中间传输量。
真正卡性能的地方往往不是语法对不对，而是派生表返回了 100 万行却只在外层取 10 行——这时候再好的索引也救不了内存和网络开销。先想清楚：这个中间结果集是否真的比直接 JOIN 更小？有没有必要先聚合再关联？如果答案模糊，不如从 EXPLAIN (ANALYZE, BUFFERS) 开始看第一行实际扫描了多少页。
