多数时候EXISTS比IN快，尤其外层表小、内层表大且有索引时；但子查询结果很小时IN更轻量；IN遇NULL返回UNKNOWN，NOT IN更危险，应优先用NOT EXISTS；派生表（FROM）比WHERE子查询更可控；MySQL 8.0的LATERAL JOIN可替代部分相关子查询，但有语法和优化限制。
IN 和 EXISTS 在子查询里到底选哪个
多数时候 EXISTS 比 IN 快，尤其当外层表小、内层表大，且子查询字段有索引时。但不是绝对——如果子查询结果集很小（比如几十行），IN 反而更轻量，因为优化器可能走哈希匹配；而 EXISTS 每次都要触发相关子查询的执行逻辑。
关键看执行计划：EXISTS 是“只要找到一行就停”，IN 默认会把子查询结果全算出来（除非优化器重写为半连接）。所以当子查询含 NULL 值时，IN 会整体返回 UNKNOWN，导致查不到数据，这是最常踩的坑。
- 用
IN前先确认子查询结果不含NULL，或显式加WHERE col IS NOT NULL - 用
EXISTS时，子查询SELECT后面写什么不重要（习惯写SELECT 1），数据库只关心是否存在行 - MySQL 5.7+ 对
IN (subquery)有物化优化，但遇到ORDER BY或LIMIT就可能失效
子查询放在 WHERE 还是 FROM 里更安全
放在 FROM 里（即派生表）通常更可控：能明确别名、可加索引提示、避免被优化器错误重排逻辑顺序。而 WHERE 中的子查询，尤其是相关子查询，容易因外层数据量大导致重复执行，性能雪崩。
典型陷阱是 MySQL 5.6 及更早版本对 FROM 子查询默认不生成临时表索引，导致 JOIN 时变全表扫描。8.0 起支持对派生表自动内联（derived_merge=on），但遇上 GROUP BY、DISTINCT 或聚合函数就会禁用该优化。
- 如果派生表结果固定且不大，加
CREATE TEMPORARY TABLE手动建索引更稳 - 避免在
WHERE里写多层嵌套的相关子查询，改用LEFT JOIN+IS NULL等价重写 - PostgreSQL 中派生表默认物化（
MATERIALIZED），但可加NOT MATERIALIZED强制内联，需按实际执行计划权衡
NOT IN 为什么经常查不出数据
因为 NOT IN 遇到子查询返回任意一个 NULL，整个表达式就变成 UNKNOWN，而 WHERE 只接受 TRUE，结果集直接为空——这不是 bug，是 SQL 三值逻辑的必然表现。
很多人以为加了 IS NOT NULL 判断就能绕过，其实不行：外层条件和子查询的 NULL 判定是分离的。唯一可靠解法是改用 NOT EXISTS，它天然规避 NULL 传染问题。
-
NOT IN (SELECT x FROM t)→ 改成NOT EXISTS (SELECT 1 FROM t WHERE t.x = outer.col) - 如果必须用
NOT IN，子查询务必加WHERE x IS NOT NULL，且确保该列在业务上允许过滤掉空值 - Oracle 对
NOT IN的处理更激进，哪怕子查询没返回数据（空结果集），也会让整条语句返回空——这点和 PostgreSQL/MySQL 都不同
MySQL 8.0 的 LATERAL JOIN 能替代大部分嵌套子查询吗
能，但只适用于“右侧依赖左侧”的场景，比如外层每行要驱动一次子查询计算。它比相关子查询更清晰，也更容易被优化器并行或下推条件。不过目前仅限于 FROM 子句，不能用于 SELECT 或 WHERE 表达式中。
一个常被忽略的限制是：LATERAL 子查询里不能引用更外层的表（即不支持跨级相关），而传统相关子查询可以。另外，如果 LATERAL 查询里用了窗口函数或 CTE，某些版本会拒绝执行或退化成嵌套循环。
- 代替
SELECT *, (SELECT ... FROM t2 WHERE t2.id = t1.ref) AS val，可用LATERAL (SELECT ...) AS v - 注意
LATERAL后面必须跟子查询，不能跟表名或视图名，否则语法报错：ERROR 1248: Every derived table must have its own alias - 在复杂报表场景中，LATERAL 容易让执行计划变得不可预测，建议配合
EXPLAIN FORMAT=TREE观察是否真的下推了关联条件
嵌套查询真正难的不是语法，而是搞清哪一层在“控制执行时机”、哪一层在“提供数据上下文”。很多慢查询的根因，其实是把本该一次性计算的子查询，写成了对外层每一行都重复执行的相关子查询——而这个区别，光看 SQL 文本很难一眼识别。
