EXISTS通常比IN快因半连接可短路，但子查询无索引或优化器未识别时可能更慢；IN在含NULL时失效且易物化，而INNER JOIN会重复行，三者语义与性能场景不同。
EXISTS 为什么通常比 IN 快，但有时反而更慢？
因为 EXISTS 是半连接（semi-join），只要找到一条匹配就短路返回；而 IN 在子查询结果含 NULL 时会整体失效（SQL 标准规定 x IN (1, NULL) 永远为 UNKNOWN），且多数数据库会对 IN 子查询先物化成临时结果集，再做哈希或遍历——这在子查询大、外层小的时候特别吃亏。
但注意：如果子查询本身没索引、又没加 LIMIT 1，某些优化器（如旧版 MySQL）可能无法识别 EXISTS 的短路意图，仍全表扫描内表；此时加上 WHERE ... AND ROWNUM = 1（Oracle）或 LIMIT 1（PostgreSQL/MySQL 8.0+）能帮优化器确认“只找一个”。
-
IN子查询返回空结果时，整个条件为FALSE；但返回NULL时，整行被过滤（不是NULL，而是逻辑上不满足） - PostgreSQL 对
IN (SELECT ...)会自动改写为EXISTS，前提是子查询无聚合、无DISTINCT、无GROUP BY - SQL Server 中，
IN和EXISTS在执行计划里经常生成相同计划，差异主要来自统计信息是否准确
INNER JOIN 不等于 EXISTS，别乱替换成连接
这是最常踩的坑：INNER JOIN 会产生笛卡尔积效应——只要右表有 3 行匹配左表某一行，结果就多出 2 行；而 EXISTS 和 IN 都是布尔语义，只关心“有没有”，不改变主表行数。
比如查“有订单的用户”，用 INNER JOIN users u ON u.id = o.user_id 可能返回重复用户（一个用户多个订单）；但 EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) 保证每个用户只出现一次。
- 若业务逻辑本就需要订单字段（如订单时间、金额），那
INNER JOIN合理，但记得加DISTINCT或用GROUP BY去重（除非明确要展开） - 若只是过滤，且右表可能有大量重复关联值，
INNER JOIN会放大中间结果集，内存和网络开销陡增 - 某些数据库（如 MySQL 5.7）对
JOIN的驱动表选择不智能，当小表在右、大表在左时，可能被迫走嵌套循环而非哈希连接
子查询展开（subquery unnesting）被禁用的典型场景
优化器想把 IN 或 EXISTS 子查询“展开”成 JOIN 来提速，但以下情况它会放弃：子查询含聚合（COUNT(*)）、含 DISTINCT、含相关列但外层有 GROUP BY、或子查询里用了不可展开的函数（如 SYSDATE、RANDOM()）。
例如：WHERE id IN (SELECT user_id FROM logs WHERE created_at > SYSDATE - 1)，因 SYSDATE 是运行期值，优化器不敢提前展开，只能走 FILTER + INDEX RANGE SCAN（Oracle）或 MATERIALIZE（PostgreSQL）。
- PostgreSQL 中可通过
SET enable_material = off强制禁用物化，逼它尝试哈希连接——但仅限调试，线上慎用 - Oracle 的
/*+ UNNEST */提示可强制展开，但若子查询含ROWNUM或CONNECT BY，提示会被忽略 - SQL Server 的
OPTION(RECOMPILE)能让参数嗅探更准，间接提升子查询展开成功率
真实慢查询诊断：先看执行计划，再动 SQL
别猜。同一个 EXISTS 语句，在不同数据分布下性能可能差十倍。重点看三处：rows 预估 vs 实际、是否走了索引、子查询是否被标记为 MATERIALIZE 或 DEPENDENT SUBQUERY。
比如 MySQL 的 EXPLAIN 输出里出现 select_type = DEPENDENT SUBQUERY，说明每行外层都要重新执行一次子查询——这时哪怕加了索引也救不了，得重构（如提前把子查询结果存进临时表，或改用 JOIN + DISTINCT）。
- PostgreSQL 用
EXPLAIN (ANALYZE, BUFFERS)，关注Actual Rows和Buffers字段，判断是否缓存命中 - SQL Server 看
Estimated Subtree Cost占比，超过 40% 就值得单独优化子查询 - 避免在子查询里写
SELECT *，即使只用一列，也要显式写出字段名——某些优化器会因此拒绝展开
复杂点往往不在语法选哪个，而在子查询是否引入了隐式类型转换、是否触发了全表扫描、以及统计信息是否过期。这些比纠结 IN 还是 EXISTS 更影响实际性能。
