子查询应优先用于WHERE子句而非SELECT列表，因其兼容性好、适配单值比较与存在性判断；关联子查询须显式写WHERE条件防笛卡尔积；重复子查询宜用WITH优化；GROUP BY后需用子查询或窗口函数获取非聚合字段。
子查询用在 WHERE 里，别直接套 SELECT 列表
很多人一想“简化复杂查询”，就往 SELECT 子句里硬塞子查询，结果报错 Subquery returns more than 1 row 或语法不支持。这不是子查询不行，是放错了位置。
WHERE 是最安全、最常用、兼容性最好的子查询落点。它天然适配单值比较（=、IN）、存在性判断（EXISTS），也支持关联条件。
-
IN适合匹配多值：比如查“所有订单金额高于平均值的客户”，用WHERE amount > (SELECT AVG(amount) FROM orders)比先算均值再 JOIN 更直白 - 用
EXISTS替代IN防 NULL：当子查询可能返回NULL时，NOT IN (subquery)会意外全不匹配，改用NOT EXISTS更可靠 - MySQL 5.7+、PostgreSQL、SQL Server 都支持标量子查询（返回单行单列）在 WHERE 和 SELECT 中；但 SQLite 对 SELECT 中的子查询限制较多，优先塞到 WHERE
关联子查询要加 WHERE 关联条件，否则变笛卡尔积
写 SELECT name, (SELECT COUNT(*) FROM orders WHERE orders.user_id = users.id) 这类关联子查询时，漏掉 WHERE orders.user_id = users.id 就等于没关联——子查询会独立执行，对每个用户都算一遍全表订单数，性能崩盘，结果还错。
关键不是“能不能写”，是“有没有真正连上外层表”。数据库不会自动猜你想要哪条关联路径。
- 检查子查询里的表别名是否和外层冲突，比如外层用
u，子查询又用u，容易误引用 - PostgreSQL 允许在子查询中用
OUTER REFERENCE（如u.id），但 MySQL 要求显式写出完整关联条件，不能依赖列名推断 - 如果发现查询变慢十倍以上，先看执行计划里子查询是不是被标记为
DEPENDENT SUBQUERY却没走索引——大概率是关联条件缺失或字段没索引
用 WITH 替代重复子查询，尤其跨多个字段或多次引用
当同一个子查询在 SELECT、WHERE、ORDER BY 里反复出现（比如 (SELECT MAX(created_at) FROM logs WHERE logs.user_id = u.id)），每次执行都重算，既慢又难维护。这时候 WITH 不是“高级技巧”，是必要优化。
它把计算结果物化成临时命名结果集，后续直接引用，逻辑清晰，执行器也更容易复用中间结果。
- MySQL 8.0+、PostgreSQL、SQL Server 2005+ 都支持标准
WITH；SQLite 支持但不支持递归；MariaDB 10.2+ 开始支持 - 别在
WITH里写无过滤的全表扫描子查询，比如WITH tmp AS (SELECT * FROM huge_table)—— 它真会先把整张表读进内存 - 如果只需要一次计算且只用在一个地方，单个子查询更轻量；只有重复 2 次及以上、或子查询本身较重时，
WITH才值得引入
GROUP BY 后不能直接用非聚合字段，子查询是绕过限制的常见方式
想查“每个部门工资最高的员工姓名”，直接 SELECT dept, MAX(salary), name FROM emp GROUP BY dept 会报错：name 不在 GROUP BY 里，也不是聚合函数。这不是 bug，是 SQL 标准防止歧义的保护机制。
子查询在这里不是炫技，而是唯一合规解法之一。要么用窗口函数（ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC)），要么用相关子查询兜底。
- 典型写法：
SELECT * FROM emp e1 WHERE salary = (SELECT MAX(salary) FROM emp e2 WHERE e2.dept = e1.dept) - 注意去重：同一部门多个员工并列最高工资时，这个写法会返回全部；若只要一条，得加
LIMIT 1或改用窗口函数取ROW_NUMBER = 1 - 性能敏感场景慎用——子查询在每行都执行一次，数据量大时不如先建部门最大工资临时表再 JOIN
子查询真正难的不是语法，是判断该不该用、在哪一层用、以及外层和内层的数据粒度是否对齐。粒度错位，再对的语法也出错结果。
