Mysql--基础知识点--94.1--嵌套子查询转关联查询
什么是嵌套子查询？为什么要改成关联查询？
嵌套子查询（Non-correlated subquery）是指子查询独立于外层查询，不引用外层的列。它先执行子查询得到结果集，然后外层查询利用这个结果集进行过滤或计算。
关联子查询（Correlated subquery）是指子查询引用了外层查询的列，对外层每一行都要执行一次子查询（通常可以利用索引快速判断）。
在某些场景下，将嵌套子查询改写成关联查询（如EXISTS或JOIN）可以大幅提升性能，避免子查询产生巨大的中间结果集，或者避免NULL带来的逻辑陷阱。
典型改写场景：IN→EXISTS
原始嵌套子查询（使用IN）
-- 找出所有下过至少一单的客户SELECT*FROMcustomersWHEREcustomer_idIN(SELECTcustomer_idFROMorders-- 子查询独立，不依赖外层);执行逻辑：
- 先完整执行子查询：从
orders表中取出所有customer_id，可能几十万行。 - 将结果集去重并构建哈希表。
- 对
customers每一行检查customer_id是否在哈希表中。
问题：如果orders表非常大（几百万行），子查询结果集巨大，会消耗大量内存和 I/O。
改写为关联查询（使用EXISTS）
SELECT*FROMcustomers cWHEREEXISTS(SELECT1FROMorders oWHEREo.customer_id=c.customer_id-- 关联条件);执行逻辑（实际优化器会做半连接）：
- 遍历
customers表（假设只有几千行）。 - 对每个客户，在
orders表的索引上快速查找是否存在该客户的订单，找到一行就立即返回TRUE，不再继续扫描。 - 整个过程无需物化庞大的订单 ID 集合。
优势：
- 当外表小、内表大时，
EXISTS通常远快于IN。 - 避免了大结果集的物化，内存压力小。
- 可以利用
orders.customer_id上的索引。
另一种改写：嵌套子查询 →JOIN（关联查询）
-- 同样查询有订单的客户，使用 JOIN（注意去重）SELECTDISTINCTc.*FROMcustomers cJOINorders oONc.customer_id=o.customer_id;注意：JOIN可能导致客户重复（一个客户有多笔订单），所以需要DISTINCT。如果customers.customer_id是主键，DISTINCT的开销通常可接受。
性能特点：
- 数据库优化器可能将
IN或EXISTS转换为类似的JOIN执行计划。 - 但显式
JOIN有时更灵活，可以同时获取订单表的其他字段。
什么时候不应该改写？
- 子查询结果集很小（如几十行）且不经常执行：
IN写法更直观，性能差异可忽略。 - 需要判断
NOT IN且子查询无NULL：但最好还是用NOT EXISTS或LEFT JOIN避免NULL陷阱。 - 子查询是标量查询（返回单个值），例如
SELECT ... WHERE salary > (SELECT AVG(salary) FROM employees)，这种无法简单改成关联查询，因为子查询只需执行一次。
总结对照表
| 写法 | 子查询类型 | 执行次数 | 适用场景 |
|---|---|---|---|
IN (SELECT ...) | 嵌套（非关联） | 子查询执行1次 | 子查询结果集小，且外表大 |
EXISTS (SELECT ... WHERE 关联) | 关联 | 外表每行执行1次（但可提前终止） | 外表小，内表大，且内表有索引 |
JOIN ... ON 关联 | 关联 | 一次连接操作 | 需要同时获取两表数据，注意去重 |
核心建议：
- 默认优先考虑语义清晰，但遇到性能问题时，把嵌套子查询（特别是
IN和NOT IN）改写成关联查询（EXISTS或JOIN）是非常有效的优化手段。 - 使用
EXPLAIN观察执行计划，确认数据库是否自动做了优化。