子查询在WHERE中慢因每行重复执行致N×M复杂度，应改JOIN或确保索引与类型一致；EXISTS适合存在性判断，IN适合固定值匹配但需防NULL；标量子查询需LIMIT 1和COALESCE防错；相关子查询须检查关联条件及EXPLAIN中的DEPENDENT SUBQUERY标识。
子查询写在 WHERE 里，为什么慢得像卡住？
因为数据库可能对每行都执行一次子查询，变成 N×M 复杂度。尤其当外部表大、子查询又没走索引时，EXPLAIN 一看就是 DEPENDENT SUBQUERY —— 这是性能红灯。
- 优先把
IN (SELECT ...)改成JOIN：MySQL 5.6+、PostgreSQL、SQL Server 都能更好优化JOIN计划 - 如果必须用
IN，确保子查询返回列有索引，且类型和外层字段严格一致（比如user_id INT对orders.user_id INT，别混BIGINT） - 避免在子查询里用
ORDER BY或LIMIT（除非配合EXISTS判断存在性）—— 它们不会提速，反而阻止优化器重写
EXISTS 和 IN，到底该选哪个？
不是语法偏好问题，是语义和执行路径差异。EXISTS 只关心“有没有一行满足”，找到就停；IN 默认要收齐全部结果再比对，还容易因 NULL 行为出错。
- 查“是否存在关联记录”：无条件选
EXISTS，例如SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) - 查“匹配某组固定值”：用
IN，但注意IN (SELECT ...)中只要子查询返回任意NULL，整条逻辑就变UNKNOWN，结果可能为空——加WHERE col IS NOT NULL拦一下 - PostgreSQL 对
IN和= ANY(ARRAY[...])优化较好，但 MySQL 8.0 前对IN子查询的物化支持弱，别依赖它自动优化
SELECT 中嵌套子查询（标量子查询），怎么防崩溃？
标量子查询（返回单值）放在 SELECT 列表里，看着简洁，实则危险：它会在结果集每行都执行一次，且一旦子查询不返回或返回多行，直接报错 Subquery returns more than 1 row 或 NULL。
- 务必加
LIMIT 1（配合ORDER BY明确取哪条），并用COALESCE(..., default_value)包一层防NULL - 更稳的做法是提前
LEFT JOIN+GROUP BY或窗口函数替代，比如用MAX()/STRING_AGG()聚合后关联 - MySQL 8.0+ 支持
LATERAL（需开启），能让子查询“感知”外层字段，比老式标量子查询可控得多，但注意EXPLAIN仍可能显示为DERIVED
相关子查询被误当成独立子查询，为什么结果不对？
典型症状：子查询里漏写了关联条件，比如写成 (SELECT COUNT(*) FROM logs) 而不是 (SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id)。它不再“相关”，变成对全表统计，每行都返回同一个总数。
- 检查子查询里是否每个外层表字段都带了别名前缀（
u.id而非裸id），这是最快速的自查方式 - 在 PostgreSQL 或 SQL Server 中，可以用
EXPLAIN ANALYZE看实际执行计划里有没有Correlated标记；MySQL 的EXPLAIN则看select_type是否为DEPENDENT SUBQUERY - 相关子查询无法并行，也很难被物化，高并发下容易拖垮连接池——线上关键查询尽量避免在
SELECT或WHERE里放三层以上嵌套的相关子查询
子查询优化不是替换语法那么简单，关键是看执行计划里它到底怎么跑的。很多“看起来一样”的写法，在不同版本、不同数据分布下，执行路径天差地别。别信直觉，先 EXPLAIN，再改。
