优先用IN处理小结果集子查询，EXISTS适用于主表小、子表大且有索引的关联场景；NOT IN存在NULL陷阱，应改用NOT EXISTS；实际性能取决于执行计划、索引与驱动顺序。
子查询结果小，优先用 IN
IN 适合子查询返回几十到几百个值的场景。比如查“属于某几个固定部门的员工”或“匹配少量预设 ID 列表”，数据库会先执行子查询、缓存结果（如 [101, 105, 108]），再用哈希或二分快速比对主表字段。
- 子查询没关联外层字段（即不依赖主表某列）时，
IN更自然，也更容易被优化器物化 - 若子查询字段有索引（如
SELECT id FROM product WHERE type = 'book'），IN执行快且稳定 - 注意：子查询结果含
NULL会导致整条IN条件判为UNKNOWN，结果为空——这是静默陷阱
主表小、子表大且有索引，选 EXISTS
EXISTS 是相关子查询，每拿主表一行就去子表按条件探查，找到第一个匹配就停。它不构造中间结果集，内存友好，且能充分利用子表上的索引。
- 典型场景：查“订单表里有支付记录的用户”，主表是
user（几千行），子表是payment（上千万行），且payment.user_id有索引 -
EXISTS子查询里写SELECT 1就够了，不用SELECT *或具体字段 - 不怕子查询返回
NULL，EXISTS只看“有没有行”，NULL不影响逻辑
NOT IN 很危险，一律改用 NOT EXISTS
NOT IN 在子查询结果含 NULL 时必然返回空——因为 value NOT IN (1, 2, NULL) 等价于 value != 1 AND value != 2 AND value != NULL，而后者永远为 UNKNOWN。
-
NOT IN无法走索引，基本等于全表扫描 -
NOT EXISTS仍可利用子表索引，并保持语义正确 - 示例：要查“没下过单的用户”，必须写
WHERE NOT EXISTS (SELECT 1 FROM order WHERE order.user_id = user.id)，而不是WHERE user.id NOT IN (SELECT user_id FROM order)
别迷信“EXISTS 总是更快”的经验
现代数据库（如 MySQL 8.0+、PostgreSQL）的优化器能自动重写部分 IN 为半连接（semi-join），性能接近 EXISTS。但以下情况仍需人工干预：
- 子查询嵌套三层以上，优化器可能放弃重写
-
IN子查询含复杂计算或函数（如DATE(created_at)），导致无法索引 - 主表数据极少（如只查 1–2 行），但子查询结果集极大（百万级），此时
EXISTS的逐行探查反而更稳
真正决定快慢的不是关键字本身，而是驱动顺序、索引覆盖和 NULL 处理——先看执行计划里的 type 和 rows，再动手改写。
