优先用EXISTS而非IN：IN对NULL敏感易致结果丢失，EXISTS只判断存在性且性能更稳；相关子查询应转为聚合+JOIN，或确保关联字段有匹配索引，深层嵌套需重写逻辑。
子查询在WHERE里用IN还是EXISTS更靠谱
多数人直觉选 IN，但遇到空值或大数据量时容易查不出结果或变慢。根本原因是 IN 对 NULL 敏感：只要子查询返回任意一个 NULL，整条 IN 判断就变成 UNKNOWN，导致行被过滤掉；而 EXISTS 只关心是否存在匹配行，不care NULL。
实操建议：
- 查“存在性”（比如“找出所有有订单的用户”）——优先用
EXISTS，语义清晰且通常更快 - 子查询结果确定非空、且数量小（IN 可读性好，MySQL 8.0+ 和 PostgreSQL 会自动优化成半连接
- 子查询含
GROUP BY或聚合后可能出NULL——别碰IN，改用EXISTS或显式加IS NOT NULL
示例：下面这条会漏掉某些用户，如果 orders.user_id 有 NULL
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders);
换成这个更稳：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
LEFT JOIN + WHERE IS NULL vs NOT EXISTS 怎么选
两者都常用来查“没有关联记录”的数据（比如“没下过单的用户”），但执行计划和语义边界不同。MySQL 有时把 LEFT JOIN ... WHERE xxx IS NULL 误判为可提前终止，实际扫描更多行；而 NOT EXISTS 的语义更贴近优化器的“反向半连接”推断。
实操建议：
- 明确要排除关联表中的所有匹配项——用
NOT EXISTS，逻辑干净，各数据库优化器识别度高 - 需要同时取左表字段 + 关联表的某些默认值（比如设为
'N/A'）——必须用LEFT JOIN，NOT EXISTS拿不到右表字段 - 右表有复合索引（如
(user_id, status)）且带条件（如status = 'paid'）——NOT EXISTS更容易命中索引，LEFT JOIN可能因WHERE下推失败而全表扫右表
JOIN多表时，子查询当派生表（FROM子句）的代价在哪
把子查询塞进 FROM（即派生表）看似封装清晰，但 MySQL 5.7 及更早版本会强制物化（写临时表），PostgreSQL 会尽量内联，SQL Server 则取决于统计信息是否足够新。这意味着：你写的“简洁子查询”，可能在执行时变成磁盘临时表 + 全字段扫描。
实操建议：
- 子查询只选几列、且外层只用其中1–2列——直接展开成 JOIN，避免无谓字段传输
- 子查询含
LIMIT/OFFSET或窗口函数（如ROW_NUMBER()）——保留为派生表是合理选择，否则逻辑无法平移 - 用
EXPLAIN看执行计划：若出现Using temporary或Materialize，就得警惕——尤其当子查询结果集 > 1万行 - MySQL 8.0+ 可尝试加
/*+ NO_MERGE() */提示来阻止内联，但仅限调试，上线前务必验证性能
相关子查询为什么一跑就慢，有没有救
相关子查询（比如 SELECT (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) cnt FROM users u）本质是“对主表每行执行一次子查询”，O(n×m) 复杂度。即使加了索引，也挡不住逐行触发的开销。
实操建议：
- 第一反应不是优化子查询，而是看能不能转成聚合 + JOIN：先
GROUP BY user_id统计，再和users表LEFT JOIN，效率通常提升数倍 - 实在要保留相关子查询——确保子查询里的关联字段（如
o.user_id）有索引，且类型和主表完全一致（比如都是BIGINT，别一边是INT一边是VARCHAR） - PostgreSQL 中可考虑用
LATERAL替代部分相关子查询，它允许子查询引用左侧表别名，且优化器更容易做延迟物化 - 别指望加索引就能“治好”深层嵌套的相关子查询——三层以上基本该重写逻辑了
复杂点不在语法，在于执行引擎如何调度数据流。同一个 SQL，换张表、换个版本、甚至换条查询条件，物理执行路径都可能突变。盯住 EXPLAIN ANALYZE 输出的实际行数和循环次数，比背口诀管用。
