嵌套查询不直接提高效率，真正提升分析效率的是在合适位置使用合适类型子查询并配合索引和执行计划验证；WHERE中IN适合小结果集，EXISTS适合大结果集且更安全；SELECT列表中慎用相关子查询。
嵌套查询本身不直接“提高效率”，用错反而拖慢十倍；真正提升分析效率的是：在合适位置用合适类型子查询，配合索引和执行计划验证。
WHERE 中用 IN 还是 EXISTS？看结果集大小
当子查询返回结果较少（比如几十行），IN 和 EXISTS 性能接近；但一旦子查询结果变大（如上万行），IN 会把整个结果集加载进内存做哈希匹配，而 EXISTS 只需判断“是否存在一行满足条件”，找到即停。
- 用
EXISTS替代IN的典型场景：查“有订单的客户”——SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id) - 避免写
IN (SELECT ...)且子查询无索引：如果orders.customer_id没索引，外层每查一个客户，都要全表扫一遍orders -
NOT IN有陷阱：只要子查询返回任意NULL，整个条件恒为FALSE；改用NOT EXISTS更安全
SELECT 列表里放子查询？只限标量、且慎用
在 SELECT 中写子查询（如统计每个用户的订单数），本质是“对主表每一行都执行一次子查询”，属于相关子查询，性能杀手。
- 可接受的情况：主表很小（
- 更优替代：
LEFT JOIN+GROUP BY，或 CTE 预聚合——WITH user_order_cnt AS (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id) SELECT u.*, c.cnt FROM users u LEFT JOIN user_order_cnt c ON u.id = c.user_id - 别写
SELECT name, (SELECT MAX(price) FROM products p WHERE p.category = u.category) FROM users u：category 字段没索引时，每次都要扫全表products
FROM 中的子查询（派生表）要命名，且优先物化
放在 FROM 后的子查询会被数据库当作临时表处理，合理使用能大幅减少重复计算，但必须显式加别名，否则语法报错。
- 必须写别名：
SELECT dept, avg_salary FROM (SELECT dept, AVG(salary) avg_salary FROM employees GROUP BY dept) <code>t，漏掉t直接报错 - 适合场景：需要多次引用同一中间结果（如部门均薪、城市销量排名）、或要做分页/去重前置处理
- 注意 MySQL 5.7 及更早版本不支持在派生表中直接引用外部列（即不支持相关派生表），升级到 8.0+ 或改用 CTE
- 如果派生表结果很大（百万行），确认是否真的需要——有时先
CREATE TEMPORARY TABLE并建索引，比反复执行子查询更稳
最常被忽略的一点：嵌套层级超过两层后，几乎无法靠肉眼判断执行顺序和索引是否生效。务必对最终 SQL 执行 EXPLAIN（MySQL）或 EXPLAIN ANALYZE（PostgreSQL），盯着 select_type 是 DEPENDENT SUBQUERY 还是 SUBQUERY，以及 rows 和 Extra 字段——这才是效率的真实刻度。
