IN和EXISTS无绝对性能优劣，效率取决于驱动表大小、子查询结果集大小及索引可用性；IN适合子查询结果集小且主表大而有索引的场景，EXISTS适合主表小、子查询表大且关联字段有索引的场景，NOT IN必须替换为NOT EXISTS以避免NULL导致逻辑错误。
IN 和 EXISTS 没有绝对的“谁更高”，效率取决于驱动表大小、子查询结果集大小、索引可用性这三个实际因素，而不是简单看“内表大还是外表大”。
IN 适合：子查询结果集小，主表大且有索引
-
IN会先执行子查询，把结果集加载进内存（或临时哈希结构），再对主表做一次扫描匹配 - 如果子查询返回几十或几百条记录（比如
SELECT id FROM config WHERE type = 'active'），而主表有百万行但WHERE id IN (...)能走id索引，这时IN往往更快 - 常见错误：把大表子查询硬塞进
IN，例如WHERE order_id IN (SELECT order_id FROM huge_log_table WHERE ...)—— 这会导致内存暴涨、全表扫描主表、甚至 OOM - 注意：MySQL 8.0+ 对
IN的常量列表做了优化，但对子查询仍按传统流程处理
EXISTS 适合：子查询表大，主表小，且子查询字段有索引
-
EXISTS是以主表为驱动，逐行调用子查询（类似for row in main_table: if exists(...) then output） - 每次子查询能命中索引（如
WHERE b.id = a.id，且b.id有索引），就只需一次索引查找，总开销 ≈ 主表行数 × 单次索引查找 - 测试中常见现象：主表 2 万行，子查询来自 30 万行的大表，且子查询条件能走索引 →
EXISTS明显快于IN - 容易踩的坑：
- 子查询里漏写关联条件（变成无关联子查询），导致全表扫描 + 恒真/恒假判断
- 关联字段未建索引，
EXISTS退化成嵌套循环全扫，比IN还慢
NOT IN 必须替换为 NOT EXISTS
-
NOT IN遇到子查询结果含NULL时，整个条件直接判为UNKNOWN，结果为空集 —— 这不是 bug，是 SQL 三值逻辑的必然行为 -
NOT EXISTS不受NULL影响，语义清晰，且子查询仍可走索引 - 即使你确认子查询字段
NOT NULL，也建议统一用NOT EXISTS：避免未来加空值后逻辑静默失效，执行计划也更稳定
真正影响性能的，从来不是语法糖本身，而是优化器是否选对了驱动表、索引是否被有效利用、结果集是否被提前剪枝。别背口诀，用 EXPLAIN 看执行计划，重点关注 type（是否 ref/range）、rows（预估扫描行数）、Extra（是否 Using index 或 Using where; Using join buffer）。
