MySQL要求FROM子句中的子查询必须带别名，否则报错“Every derived table must have its own alias”；FULL OUTER JOIN不支持，需用LEFT+RIGHT JOIN加UNION ALL模拟；IN、EXISTS、标量子查询语义与性能差异大，须按场景选用；ON中子查询会导致N×M级执行开销，应提前物化。
子查询在 FROM 子句里为什么报错“Every derived table must have its own alias”
MySQL 强制要求所有子查询出现在 FROM 中时必须带别名，否则直接报错。这不是风格问题，是语法硬性限制。
常见错误写法：SELECT * FROM (SELECT id, name FROM users WHERE status = 1) —— 缺少别名，立刻失败。
- 必须加别名，哪怕只是
t：SELECT * FROM (SELECT id, name FROM users WHERE status = 1) AS t - PostgreSQL 和 SQL Server 同样要求别名，但错误提示不同；SQLite 允许省略（但不建议依赖）
- 别名不能是保留字，比如
order、group，否则要加反引号：AS `order` - 嵌套多层子查询时，每层
FROM子查询都得有独立别名，不能复用
FULL OUTER JOIN 在 MySQL 中根本不存在怎么办
MySQL 直到 8.0.32 仍不支持 FULL OUTER JOIN，试图写会报错 Unknown type of JOIN。这不是配置或版本升级能解决的，是引擎级缺失。
替代方案本质是用 LEFT JOIN + RIGHT JOIN + UNION ALL 拼出全集：
SELECT u.id, u.name, o.order_id FROM users u LEFT JOIN orders o ON u.id = o.user_id UNION ALL SELECT NULL, NULL, o.order_id FROM orders o WHERE o.user_id NOT IN (SELECT id FROM users WHERE id IS NOT NULL);
- 注意
UNION ALL比UNION快，且此处逻辑上不会重复，无需去重 -
NOT IN对NULL敏感，务必补上WHERE id IS NOT NULL，否则右边没匹配的行可能被过滤掉 - 如果关联字段允许
NULL，改用NOT EXISTS更安全：WHERE NOT EXISTS (SELECT 1 FROM users u2 WHERE u2.id = o.user_id) - 性能上，这个写法无法利用复合索引优化右半部分，大表慎用；优先考虑业务是否真需要全连接
子查询当条件 vs 当字段：IN、EXISTS、标量子查询怎么选
同样查“哪些用户下过单”，IN、EXISTS、= (SELECT ...) 行为和性能差异极大，不能随便换。
-
IN对空结果集返回空（不是FALSE），且左侧字段为NULL时整个条件为UNKNOWN，容易漏数据 -
EXISTS是半连接，只关心是否存在，通常比IN快，尤其子查询结果大时；且不受NULL影响 - 标量子查询（如
SELECT name FROM users WHERE id = (SELECT user_id FROM orders LIMIT 1)）要求子查询**严格返回一行一列**，否则运行时报错Subquery returns more than 1 row - 如果子查询可能无结果，标量写法会返回
NULL，而IN或EXISTS则按布尔逻辑处理，语义不同，别混用
JOIN 带子查询时，ON 里写子查询为什么慢得离谱
在 ON 条件中放子查询（比如 ON u.id = (SELECT user_id FROM logs WHERE log_time = MAX(log_time))）会导致该子查询对左表每一行都执行一次，O(n×m) 级别开销。
- 绝大多数情况应该把子查询提前物化成临时表或 CTE，再 JOIN：
WITH latest_log AS (SELECT user_id, MAX(log_time) AS max_t FROM logs GROUP BY user_id) - MySQL 5.7 不支持 CTE，可用派生表代替，但记得加别名并确保能走索引
- 检查执行计划：
EXPLAIN中若出现select_type = DEPENDENT SUBQUERY，基本就是性能雷区 - 有些看似简单的子查询（如
(SELECT COUNT(*) FROM comments c WHERE c.post_id = p.id)）也应改用LEFT JOIN ... GROUP BY预聚合
复杂关联的本质不是“能不能写出来”，而是“数据库能不能高效执行”。别让子查询躲在 JOIN 条件里偷偷拖垮查询。
