必须加别名，这是SQL标准强制要求的语法底线——不加则报错；子查询在FROM中被视为派生表，必须有唯一标识符才能绑定列引用，主流数据库均抛出“Every derived table must have its own alias”错误。
FROM子句里直接写子查询必须加别名
SQL标准要求，FROM中出现的子查询（即派生表）必须显式指定别名，否则多数数据库会报错 ERROR: subquery in FROM must have an alias。这不是可选项，是语法硬性约束。
常见错误是只写 SELECT * FROM (SELECT user_id, COUNT(*) FROM logs GROUP BY user_id)，漏掉别名，结果执行失败。
- 正确写法：在子查询末尾紧跟一个合法标识符，如
AS user_stats或简写为user_stats - 别名不能是保留字，比如
order、group会触发语法错误，优先用下划线命名，如user_activity - MySQL 8.0+、PostgreSQL、SQL Server 都严格遵循此规则；SQLite 虽宽松但建议统一加别名，避免迁移问题
子查询字段必须明确，不能依赖外部列
派生表是独立作用域，其内部无法引用 FROM 外层的表或列。比如不能在子查询里写 WHERE log_time > outer_table.start_date —— 这属于相关子查询，只允许出现在 SELECT 或 WHERE，不能放 FROM。
典型误用场景：想先按日期范围过滤再聚合，却把条件错塞进派生表里，导致逻辑偏差或报错。
- 正确做法：过滤逻辑放在外层
WHERE，或在子查询内用常量/参数（如WHERE log_time >= '2024-01-01'） - 若需动态过滤，考虑用 CTE 替代，例如
WITH recent_logs AS (SELECT * FROM logs WHERE log_time >= ?) SELECT ... FROM recent_logs ... - 字段名在子查询中要唯一，否则外层
SELECT *可能因重名报错（如两个子查询都选了id）
性能关键：派生表不自动走索引，注意物化开销
数据库通常不会为派生表自动创建索引，这意味着外层对派生表的 JOIN 或 WHERE 条件可能全表扫描。尤其当子查询返回百万行时，性能会断崖下跌。
例如：用 (SELECT user_id, MAX(created_at) FROM orders GROUP BY user_id) AS last_order 关联用户表，如果 orders 表没建好 (user_id, created_at) 复合索引，这个子查询本身就很慢。
- 先确认子查询内部是否能利用索引：看
EXPLAIN输出里是否有Using index或Index range scan - 避免在派生表里做
SELECT *，只选真正需要的字段，减少内存和传输开销 - PostgreSQL 12+ 支持
MATERIALIZEDCTE，但普通派生表仍是每次执行重算，没有缓存
替代方案：CTE 比嵌套子查询更易读和调试
功能上 CTE 和派生表等价，但写法更清晰，尤其多层统计时。比如计算「每个用户最近3次订单金额均值」，用嵌套子查询容易嵌套过深，而 CTE 可分步命名。
示例对比：
-- 派生表（难维护）
SELECT u.name, avg_orders.avg_amount
FROM users u
JOIN (
SELECT user_id, AVG(amount) AS avg_amount
FROM (
SELECT user_id, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders
) ranked
WHERE rn <= 3
GROUP BY user_id
) avg_orders ON u.id = avg_orders.user_id;换成 CTE 后，每一步都有语义化名字，改某一层逻辑不影响其他部分。
- CTE 不改变执行计划本质，但方便加注释、单独测试子逻辑（如只跑
SELECT * FROM recent_orders） - 某些旧版 MySQL（
- 不要为了“看起来高级”强行用 CTE，单层简单聚合仍推荐直接派生表，减少语法噪音
实际写的时候，先跑通子查询本身，再包一层加别名，最后补外层关联或过滤。最容易被忽略的是别名缺失和字段歧义——这两点几乎占了 70% 的初犯报错。
