FROM子句中的子查询必须加别名，否则语法错误；别名需合法且不与保留字冲突；派生表无索引、性能未必优化；ORDER BY/LIMIT须在外层；列歧义需显式前缀或重命名。

FROM 子句里的子查询必须起别名，否则直接报错

MySQL、SQL Server、PostgreSQL 都强制要求：只要子查询出现在 FROM 子句中，就必须用 AS（或省略 AS 直接跟名称）给它指定一个合法的别名。没别名就语法错误，不是警告，是硬性限制。

• 错误写法：SELECT * FROM (SELECT id, name FROM users WHERE active = 1)
• 正确写法：SELECT <em> FROM (SELECT id, name FROM users WHERE active = 1) AS active_users</em> 或 SELECT FROM (SELECT id, name FROM users WHERE active = 1) active_users
• 别名不能是保留字，比如 order、group、user（在某些方言里），否则要加反引号或双引号
• 别名作用域仅限当前查询，外部无法引用；也不能在同一个 FROM 中重复使用同一别名

WHERE 条件不能直接引用派生表里的列别名

派生表内部的列别名（比如 SELECT YEAR(orderdate) AS orderyear）对外层查询可见，但外层 WHERE 子句不能用这些别名做计算或函数包装——因为 SQL 执行顺序是 FROM → WHERE → GROUP BY → SELECT，而别名是在 SELECT 阶段才“诞生”的。

• 以下写法会失败：SELECT * FROM (SELECT id, created_at FROM logs) AS l WHERE YEAR(l.created_at) = 2025（如果数据库不支持该函数在 WHERE 中使用）
• 更稳妥的做法是把逻辑下推到派生表内部：SELECT * FROM (SELECT id, created_at FROM logs WHERE YEAR(created_at) = 2025) AS l
• 或者在外层用原始列名+函数：WHERE YEAR(l.created_at) = 2025 —— 这取决于具体数据库是否允许，MySQL 通常允许，PostgreSQL 要求函数结果可索引或显式转换

派生表性能不等于“自动优化”，反而可能拖慢查询

很多人以为“把子查询拎出来当临时表”就能提速，其实不然。派生表本身不建索引、不缓存、不复用，每次执行都重新计算。尤其当内部子查询扫描大表又没过滤条件时，开销可能比直接 JOIN 还高。

• 容易踩的坑：
  • 派生表里漏写 WHERE，导致生成百万行中间结果，再被外层 GROUP BY 或 JOIN 处理
  • 在派生表中用了 SELECT *，但外层只用其中两列，白白传输和处理冗余字段
  • 多层嵌套派生表（比如 FROM (SELECT ... FROM (SELECT ...) t1) t2），可读性崩坏且优化器容易放弃重写

典型适用场景是：需要先聚合/去重/转换，再和其他表关联，且中间结果集明显小于源表。例如：

SELECT u.name, s.total_orders FROM users u JOIN (SELECT user_id, COUNT(*) AS total_orders FROM orders GROUP BY user_id) s ON u.id = s.user_id

ORDER BY 和 LIMIT 必须放在外层，不能依赖派生表内部排序

派生表内部的 ORDER BY（除非配合 LIMIT）会被优化器忽略——因为“临时表”本身无序，排序只有在最终输出时才有意义。

• 错误预期：SELECT * FROM (SELECT id, score FROM students ORDER BY score DESC LIMIT 5) top5 → 你以为取的是全局前5，但如果没加 WHERE 约束，它只是随机 5 行排了序再返回
• 正确做法：确保内部子查询逻辑能精确缩小数据集，比如按某个维度分组后取 Top N，或先过滤再排序
• 若需稳定取前 N，推荐用窗口函数（如 ROW_NUMBER() OVER (ORDER BY score DESC)），兼容性和语义更清晰

别名冲突和列名歧义最容易在多层 JOIN 中暴露

当你把派生表和其他物理表 JOIN，又恰好它们有同名列（比如都叫 id），外层 SELECT * 或 WHERE 不加表前缀就会报错或返回意外结果。

• 解决方法只有两个：
  • 所有列显式写出并加前缀：SELECT u.id, u.name, s.total_orders
  • 在派生表里重命名易冲突字段：SELECT user_id AS uid, COUNT(*) AS cnt FROM orders GROUP BY user_id

真正难的不是写出来，而是判断“该不该用”。很多看似适合派生表的场景，用 CTE 或物化视图更可控；而简单过滤+连接，硬套派生表反而增加理解成本。