相关子查询必须出现在select、where或having中才能引用外部表字段，若写在from中则无法访问；应确保关联字段有索引，并优先用exists替代in，复杂聚合可考虑窗口函数优化。
子查询里怎么用外部表的字段
SQL标准不支持在子查询中直接引用外部查询的列（比如 WHERE id = outer.id），除非它被明确识别为相关子查询（correlated subquery）。关键在于子查询必须出现在 SELECT、WHERE 或 HAVING 中，且内部引用了外部查询的列——这时数据库引擎才会逐行执行子查询，并把当前行的值“传入”。
常见错误是把子查询写在 FROM 子句里（即派生表），这种写法无法访问外部列，会报错类似 column "t1.id" does not exist。
- ✅ 正确位置：放在
WHERE或SELECT表达式中，例如WHERE x IN (SELECT y FROM b WHERE b.ref_id = a.id) - ❌ 错误位置：写成
FROM (SELECT ... FROM b WHERE b.ref_id = a.id) AS sub—— 这里a.id在子查询作用域外不可见 - ⚠️ 注意：相关子查询性能通常较差，尤其在外表大、子查询未走索引时；务必确保子查询中的关联字段（如
b.ref_id）有索引
MySQL/PostgreSQL 中相关子查询的写法差异
主流数据库都支持相关子查询语法，但行为细节有差别。比如 MySQL 8.0+ 和 PostgreSQL 允许在 SELECT 列表里用标量子查询，而旧版 MySQL（5.7）对某些嵌套层级有限制；PostgreSQL 还支持 LATERAL 显式声明依赖关系，语义更清晰。
- MySQL 示例：
SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) AS order_count FROM users - PostgreSQL 推荐写法（更可控）：
SELECT u.name, o.cnt FROM users u LEFT JOIN LATERAL (SELECT COUNT(*) AS cnt FROM orders WHERE orders.user_id = u.id) o ON true - ⚠️ MySQL 中若子查询返回多行且用于标量上下文（如
SELECT (subquery)），会报错Subquery returns more than 1 row；需加LIMIT 1或改用EXISTS
用 EXISTS 替代 IN 避免 NULL 和性能陷阱
当子查询用于存在性判断（比如“用户是否有订单”），优先用 EXISTS 而非 IN。前者不关心具体值，只判断是否存在匹配行，天然规避 NULL 导致整个条件为 UNKNOWN 的问题，且多数情况下优化器能提前终止扫描。
-
WHERE EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id)—— 安全、高效、语义明确 -
WHERE users.id IN (SELECT user_id FROM orders)—— 若orders.user_id含NULL，整条WHERE可能不返回任何结果（SQL 三值逻辑） - 注意：如果子查询里用了
SELECT *，虽不影响逻辑，但建议写SELECT 1或SELECT NULL，避免无谓字段解析开销
窗口函数能否替代部分相关子查询
很多原本靠相关子查询实现的“每行聚合”需求（如统计每个用户的订单数、最近下单时间），其实可以用窗口函数更高效地完成，而且写法更简洁、执行更快。
- 替代计数：
COUNT(*) OVER (PARTITION BY user_id)比子查询(SELECT COUNT(*) FROM orders o2 WHERE o2.user_id = o1.user_id)快得多 - 替代排名：
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)直接拿到最新订单，无需子查询找 MAX - ⚠️ 窗口函数不能替代所有场景——比如需要“用户是否有满足某复杂条件的订单”，仍得用
EXISTS或相关子查询；窗口函数只能基于当前结果集做计算，不能跨表自由过滤
EXPLAIN 看执行计划，确认子查询是否走了索引，以及是否被重复执行了 N 次。
