派生表的核心价值在于显式拆解“先算再连”逻辑，避免WHERE中相关子查询反复执行；必须加括号和语义化别名，且不可引用外层字段，性能依赖联合索引与统计信息。
派生表不是万能的中间层，但它能帮你把“先算再连”的逻辑显式拆开，避免嵌套子查询在WHERE里反复执行。
MySQL里写派生表必须加括号和别名
不加括号或漏掉别名，MySQL直接报错 Every derived table must have its own alias。哪怕只用一次，也得写成 (SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id) AS user_order_count 这种形式。
- 括号不能省：
SELECT * FROM SELECT id FROM users语法错误，必须是SELECT * FROM (SELECT id FROM users) AS t - 别名不能空：
) AS或) t后面没名字就失败；) t这种单字母合法，但建议用语义名（如active_users） - 别名作用域仅限当前查询：同一个
SELECT里不能两次引用同一个派生表别名，想复用就得重写或改用CTE（MySQL 8.0+ 支持）
用派生表替代WHERE里的相关子查询
比如查“每个用户最新一条订单”，如果写成 WHERE o.id = (SELECT id FROM orders o2 WHERE o2.user_id = u.id ORDER BY created_at DESC LIMIT 1)，MySQL会对每行 u 执行一次子查询，没索引时极慢。
- 改成派生表：先把每个用户的最新订单ID算出来，再JOIN——
(SELECT user_id, MAX(created_at) AS max_time FROM orders GROUP BY user_id) AS latest，再连orders补全字段 - 注意：派生表里不能直接引用外层字段，所以
SELECT * FROM users u JOIN (SELECT * FROM orders WHERE user_id = u.id) AS o2会报错 - 性能关键：给
orders(user_id, created_at)加联合索引，否则GROUP BY或ORDER BY + LIMIT 都可能全表扫描
PostgreSQL用LATERAL解决“每行触发一次”的需求
当真需要对外层每行动态跑子查询（比如取每个用户的前三条订单），MySQL只能靠JOIN模拟，而PostgreSQL原生支持 LATERAL。
- 必须显式写
LATERAL关键字，否则优化器当成普通JOIN，报错invalid reference to FROM-clause entry - 写法示例：
SELECT u.name, lo.order_id FROM users u, LATERAL (SELECT order_id FROM orders o WHERE o.user_id = u.id ORDER BY o.created_at DESC LIMIT 3) AS lo - 风险点：外层返回10万行，LATERAL 就执行10万次子查询——务必确认子查询有高效索引支撑，否则比全表JOIN还慢
SQL Server优先用CTE而不是多层派生表
虽然CTE（WITH 语法）在SQL Server里也不物化，但可读性远胜嵌套括号，而且能递归。
- 同样逻辑，派生表写法容易变成
SELECT * FROM (SELECT * FROM (SELECT ...) AS a) AS b，维护困难 - CTE写法：
WITH user_avg AS (SELECT user_id, AVG(score) AS avg_score FROM scores GROUP BY user_id), top_users AS (SELECT u.* FROM users u JOIN user_avg ua ON u.id = ua.user_id WHERE u.score > ua.avg_score) SELECT * FROM top_users - 注意：CTE只是语法糖，SQL Server优化器通常会内联展开，不会缓存中间结果；真要物化（比如反复引用），得用临时表或变量表
派生表真正的价值不在“临时存数据”，而在把聚合、过滤、去重这些操作从JOIN条件或WHERE里剥离出来——这样你一眼就能看出“先算什么，再连什么”，而不是在一堆ON和AND之间猜执行顺序。最容易被忽略的是：它不改变数据物理分布，所有性能瓶颈最终还是落在索引和统计信息上。
