子查询在 where 中需加括号，单值比较要求 1 行 1 列，多值用 in，存在性判断优先 exists；select 中须为标量子查询；性能差时应改用 join；相关子查询须正确关联外层字段并用 explain 验证。
子查询写在 WHERE 里最常用，但别忘了加括号
MySQL 子查询最常见的位置就是 WHERE 条件中，比如查“订单金额高于平均值的客户”。这时候必须用括号把子查询包起来，否则会报错 ERROR 1064。
常见错误现象：Subquery returns more than 1 row——说明你用了 = 却返回多行，该换 IN 或加 LIMIT 1。
- 单值比较（
=、>、）：子查询必须只返回 1 行 1 列，例如 <code>(SELECT AVG(amount) FROM orders) - 多值匹配（
IN）：子查询可返回多行，如customer_id IN (SELECT customer_id FROM vip_logs) - 存在性判断（
EXISTS）：效率通常比IN高，尤其外层表大、内层表小时；注意EXISTS子查询里一般写SELECT 1，不关心具体值
JOIN 能替代大部分子查询，性能差很多时优先改写
子查询在 WHERE 或 SELECT 中反复执行，容易拖慢查询。比如 SELECT name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) FROM users u，对每个用户都跑一遍子查询。
这种场景本质是关联统计，用 LEFT JOIN + GROUP BY 通常快 3–10 倍，尤其数据量过万后差异明显。
- 把子查询逻辑拆成显式
JOIN，例如用users LEFT JOIN orders ON users.id = orders.user_id GROUP BY users.id -
EXISTS多数情况可等价转为INNER JOIN，但语义不同：前者不重复主表行，后者可能因一对多重复 - MySQL 8.0+ 对某些相关子查询做了优化（如
WHERE x IN (SELECT ……)），但别依赖——先EXPLAIN看执行计划
SELECT 列表里的子查询必须是标量子查询
写在 SELECT 后面的子查询，MySQL 要求它只能返回一个值（1 行 1 列），叫“标量子查询”。否则直接报错 ERROR 1242: Subquery returns more than 1 row。
典型使用场景：给每行补一个聚合值，比如“每个部门的平均薪资”，但又不想用 GROUP BY 打乱原始行结构。
- 安全写法：确保子查询带
LIMIT 1或有唯一约束条件，例如(SELECT salary FROM employees e2 WHERE e2.dept_id = e1.dept_id ORDER BY hire_date DESC LIMIT 1) - 避免写
(SELECT MAX(salary) FROM employees WHERE dept_id = e1.dept_id)这种看似安全实则隐含风险的——万一没数据就返回NULL，而业务可能没处理空值 - 如果真需要每行对应多值（如 JSON 数组），MySQL 5.7+ 可用
JSON_ARRAYAGG()配合JOIN，别硬扛子查询
相关子查询容易误写成笛卡尔积，务必检查 WHERE 关联条件
相关子查询依赖外部查询的字段，比如 WHERE id = outer_table.id。漏写或写错这个关联，子查询就变成“对每一行都查全表”，实际效果等同于没关连，性能爆炸。
常见错误现象：查询几秒没反应、CPU 拉满、EXPLAIN 显示 type: ALL 且 rows 是两个表行数相乘。
- 写完立刻用
EXPLAIN看Extra字段：出现Using where; Using index是健康信号；若只有Using where，大概率关联失效 - 别在子查询里用别名混淆，例如外层是
FROM users u，子查询里却写WHERE u.id = ……——u在子查询作用域不可见，MySQL 会静默回退到全表扫描 - MySQL 8.0 支持
LATERAL（需开启），能更清晰表达相关性，但目前用得少，兼容性不如传统写法稳妥
子查询看着简单，但执行时机、作用域和优化器行为很微妙。最常被忽略的是：你以为的“一次计算复用”，MySQL 可能真的一行行重算——别信直觉，EXPLAIN 是唯一靠谱的判断依据。
