exists 不一定比 in 更适合大数据量查询，关键取决于驱动行数、索引位置和子查询结果集规模；exists 逐行驱动+短路判断，in 先物化子查询再哈希匹配；not in 存在 null 语义陷阱，应统一用 not exists。
EXISTS 不一定比 IN 更适合大数据量查询——关键看驱动行数、索引位置和子查询结果集规模，而不是“大数据量”这个模糊标签。
EXISTS 的执行逻辑：逐行驱动 + 短路判断
EXISTS 本质是对外层表（主查询）每行做一次独立的子查询调用，只要子查询命中第一行就立刻返回 TRUE 并停止扫描。它不关心内层能返回多少行，只确认“是否存在”。
- 外层表扫描 1 行 → 带入子查询条件（如
WHERE o.user_id = u.id）→ 内层表用索引快速定位 → 找到 1 行即退出 - 如果内层表的关联字段（如
o.user_id）上有索引，且外层表行数少（比如几千），这种模式开销极低 - 若外层表本身没索引，
type: ALL扫描 + 每次都触发一次内层索引查找，性能反而崩盘 - 执行计划中常见
dependent subquery或semijoin，且Extra出现Using where; Using index才算真正生效
IN 的执行逻辑：物化子查询 + 哈希匹配
IN 会先完整执行子查询，把结果全部捞出来（哪怕只用其中一两个值），再构建哈希表或排序结构，最后让外层表每一行去查这个临时集合。
- 子查询返回 99 行？内存里建个小哈希表，
IN往往比EXISTS快（实测快 10 倍不止） - 子查询返回 30 万行？物化过程吃光内存、触发磁盘临时表，
Extra显示Using temporary; Using filesort就危险了 - 外层表字段（如
u.id）有索引才能加速哈希查找；否则外层也全表扫，双重打击 - MySQL 8.0+ 会尝试将
IN重写为semijoin，但遇到GROUP BY、DISTINCT或聚合函数时大概率失败，只能硬物化
看执行计划比背口诀管用得多
别信“小表驱动大表”这种过时说法。真正要盯死的是 EXPLAIN 输出里的三列：rows、type、key。
-
rows：外层表预估扫描行数。如果EXISTS的外层rows是 200 万，基本不用试了——它会跑 200 万次子查询 -
type：外层是ALL还是ref？内层是range还是index？type: ALL出现在任何一层都意味着索引失效 -
key：有没有用上你建的索引？key: NULL就等于裸奔 - 对比时务必加
SQL_NO_CACHE，并用FORMAT=TREE（MySQL 8.0+）看清是否真走semijoin而非materialized
NOT IN 是语义陷阱，不是性能问题
只要子查询里任意一行的字段为 NULL，整个 NOT IN 表达式恒为 UNKNOWN，WHERE 直接过滤掉所有行——结果为空，不是慢，是错。
-
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM logs)：若logs.user_id允许为NULL，这条语句永远查不出数据 -
NOT EXISTS完全不受NULL影响，语义清晰，还能走索引 - 即使你当前确认字段非空，未来加约束或改表结构时可能埋雷，统一用
NOT EXISTS是底线操作
真正容易被忽略的点是：**索引是否落在“被驱动的一侧”**。EXISTS 依赖内层表索引，IN 依赖外层表索引——写法一换，索引有效性就翻转。不看执行计划直接改写，很可能越改越慢。
