相关子查询必须引用外层字段，否则变为普通子查询；需避免别名冲突、性能恶化、from中非法使用、多行返回错误，并优先用join或exists替代。
WHERE里用相关子查询，必须加外层字段引用
相关子查询不是独立运行的，它依赖外层查询的某一行数据——比如用 e1.dept_id 去匹配子查询里的 e2.dept_id。没写这个关联条件，就变成普通子查询，结果可能全错。
- 错误写法：
WHERE salary > (SELECT AVG(salary) FROM employees)—— 这算的是全公司平均，不是“当前部门”的平均 - 正确写法：
WHERE salary > (SELECT AVG(salary) FROM employees e2 WHERE e2.dept_id = e1.dept_id)——e1是外层别名，e2是子查询别名，=左右字段必须明确关联 - 别名冲突常见：外层表用了
e，子查询也用e，会导致列解析失败，必须区分
SELECT列表里放相关子查询，性能会随行数线性恶化
每查出一行，就执行一次子查询。10万员工，就执行10万次子查询——哪怕加了索引，也可能比JOIN慢几倍。
- 典型慢查询：
(SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id)放在SELECT里，u.id就是外层引用，触发相关执行 - EXPLAIN 看到
DEPENDENT SUBQUERY就该警觉，说明数据库没法提前优化 - 替代方案优先走
LEFT JOIN + GROUP BY，让聚合一次性完成，再和主表关联 - 如果只是判断“有没有”，改用
EXISTS更轻量，找到第一行就停，不统计总数
FROM里不能用相关子查询，语法直接报错
FROM 后的子查询是派生表，必须能独立执行完毕，生成确定的结果集。相关子查询要依赖外层行，根本无法在FROM阶段求值。
- 以下写法非法：
FROM (SELECT * FROM orders WHERE user_id = u.id) AS recent——u.id在外层未定义，MySQL 报错Unknown column 'u.id' in 'where clause' - 想实现类似效果，得先用
JOIN或窗口函数（如ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)）预处理 - 真要用子查询做临时表，必须确保它不引用任何外层字段，且加别名，比如
(SELECT user_id, MAX(created_at) FROM orders GROUP BY user_id) AS last_order
相关子查询返回多行时，WHERE里用=会炸，IN或EXISTS才安全
在 WHERE 子句中，= 要求子查询严格返回单行单列；一旦漏写限制条件，比如忘了 GROUP BY 或 LIMIT 1，就会报错 Subquery returns more than 1 row。
- 错误示例：
WHERE status = (SELECT status FROM logs WHERE user_id = u.id)—— 一个用户可能有多条日志，子查询返回多行 - 改用
IN：WHERE status IN (SELECT status FROM logs WHERE user_id = u.id)，语义变为“只要匹配任一状态就行” - 改用
EXISTS：WHERE EXISTS (SELECT 1 FROM logs WHERE user_id = u.id AND status = 'error')，更明确、更高效 - 真要取单值，加聚合或限制：
(SELECT MAX(created_at) FROM logs WHERE user_id = u.id)或(SELECT status FROM logs WHERE user_id = u.id LIMIT 1)
相关子查询最隐蔽的坑，是它看起来像普通子查询，但执行逻辑完全不同——它不是“先算完再用”，而是“每行都重算一遍”。别只看SQL写得短，得看执行计划里有没有 DEPENDENT SUBQUERY。
