FROM子句中嵌套SELECT必须加别名，这是SQL标准强制要求；不加则报错，如PostgreSQL提示“subquery in FROM must have an alias”，MySQL 8.0+和SQL Server同样严格，别名不可省略且须紧跟右括号。
FROM子句里嵌套SELECT必须加别名
SQL标准要求，FROM中出现的子查询（即衍生表）必须显式指定别名，否则多数数据库会报错，比如 PostgreSQL 报 ERROR: a subquery in the FROM clause must have an alias，MySQL 8.0+ 和 SQL Server 同样严格。不加别名不是“可选”，是语法硬性限制。
常见错误写法：SELECT * FROM (SELECT user_id, COUNT(*) FROM logs GROUP BY user_id) —— 这条语句在几乎所有主流引擎里都会失败。
正确做法是立刻补上别名，哪怕只是 t：
SELECT t.user_id, t.cnt FROM (SELECT user_id, COUNT(*) AS cnt FROM logs GROUP BY user_id) AS t
注意：AS 关键字可省略（如 ) t），但别名本身不可省；别名作用域仅限当前查询，不能在外部 WHERE 或 ORDER BY 中直接引用子查询里的原始列别名（除非在子查询内已定义）。
聚合结果再聚合必须用两层FROM嵌套
想对聚合结果做二次计算（比如“统计每个用户订单数后，再算订单数分布区间的人数”），不能在一个 GROUP BY 里完成——因为聚合函数不能嵌套在同级 GROUP BY 中使用（如 COUNT(COUNT(*)) 是非法的）。必须把第一层聚合作为衍生表，再在外层对其结果分组。
典型场景：查“有多少用户下了 1 单、2 单、3 单……”
- 第一层：按
user_id聚合出每人订单数 - 第二层：按第一层的
cnt分组，统计频次
SELECT cnt AS order_count, COUNT(*) AS user_count FROM ( SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id ) AS t GROUP BY cnt ORDER BY cnt
漏掉外层 GROUP BY cnt 就会得到单行结果；若忘记第一层的 AS cnt，外层就无法引用该列。
WHERE和JOIN操作必须放在外层，不能下推到衍生表内部
衍生表是一个独立的结果集，它的执行逻辑在 FROM 阶段完成，因此过滤条件如果依赖外层字段（比如关联主表的 ID），就不能写在子查询内部——那会导致语法错误或逻辑错乱。
例如，要查「每个部门平均薪资，再筛选平均薪资 > 10000 的部门」，错误写法是把 HAVING AVG(salary) > 10000 放进子查询里并试图在外层再过滤——其实这时应该直接用外层 HAVING 或 WHERE：
SELECT dept, avg_salary FROM ( SELECT dept, AVG(salary) AS avg_salary FROM employees GROUP BY dept ) AS t WHERE avg_salary > 10000
如果还要关联其他表（如部门名称表），JOIN 必须写在外层：FROM (...) AS t JOIN depts ON t.dept = depts.code；写在子查询里不仅冗余，还可能因作用域问题报错。
性能隐患：衍生表默认不走索引，大数据量需谨慎
衍生表本质是物化临时结果集（具体是否真物化取决于优化器），它不会自动继承原表的索引。当子查询返回百万行，外层再做 GROUP BY 或 JOIN，性能可能断崖式下降。
优化方向有限但明确：
- 确保子查询中
GROUP BY字段有索引（如CREATE INDEX idx_logs_uid ON logs(user_id)） - 避免在子查询里
SELECT *，只取外层真正需要的列 - PostgreSQL 可考虑用 CTE 替代（配合
MATERIALIZED控制物化行为），但 MySQL 8.0+ 的 CTE 默认不物化，效果类似衍生表 - 超复杂重组逻辑，优先评估是否应拆到应用层或用物化视图预计算
最易被忽略的一点：某些 ORM（如 Django ORM 的 subquery）生成的衍生表 SQL，可能隐式带出大量冗余字段或未加别名，上线前务必用 EXPLAIN 看执行计划，而不是只测功能正确性。
