IN适合子查询结果集小（几十至几百行）、外层表大且id有索引的场景；EXISTS适合外层行数少、内表大且关联字段有索引的场景；NOT IN必须替换为NOT EXISTS以防NULL导致逻辑错误；关键看EXPLAIN中的type、rows和Extra字段。
选型不看“表大小”，而看“子查询结果集大小”和“外层驱动行数”——这是最常被误读的起点。
IN 适合子查询结果集小、外层表大且有索引的场景
当 SELECT id FROM temp_ids WHERE batch_id = 123 只返回几十或几百行，而主表 users 有百万级数据时，IN 才真正高效。MySQL 会把子查询结果物化为哈希表，再用 users.id 的索引快速查找匹配项。
- 常见错误：以为“小表驱动大表”就该用
IN，结果子查询没加过滤条件，查出几万行，IN直接卡住 - 必须确保子查询返回结果可控——靠
WHERE条件收窄，不是靠LIMIT（语义错误） -
users.id必须有索引，否则执行计划中type: ALL会让性能断崖下跌 - 子查询里只选必要列，比如
SELECT user_id，避免SELECT *增加传输与缓存开销
EXISTS 适合外层行数少、内表大且关联字段有索引的场景
当主表只有几千行（如 users），而子查询要查的表（如 orders）有千万级数据时，EXISTS 的短路优势才凸显：对每条用户记录，代入 orders.user_id = users.id 查一次，找到第一行就停。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 陷阱：写了
EXISTS (SELECT * FROM orders WHERE orders.user_id = users.id)却没给orders.user_id建索引——每查一条用户，都全表扫orders - 子查询里写
SELECT 1而非SELECT *，既轻量，又让优化器更容易识别“只判断存在性”的意图 - 检查
EXPLAIN输出中子查询部分是否出现Using where; Using index，这是索引生效的关键信号 - 别在
EXISTS子查询里加ORDER BY或COUNT(*)，它只关心“有没有”，这些纯属浪费
NOT IN 必须无条件替换为 NOT EXISTS
只要子查询结果里有一条 NULL（比如 logs.user_id IS NULL），NOT IN 整个表达式就变成 UNKNOWN，最终查不到任何数据——这不是慢，是逻辑错误。
-
NOT EXISTS完全不受NULL影响，它只判断“是否存在满足条件的行”，语义稳定 - 即使你确认当前字段
NOT NULL，也建议统一用NOT EXISTS，避免后续改表结构时埋雷 - 改写时注意关联条件迁移：原
WHERE id NOT IN (SELECT user_id FROM logs WHERE status = 'active')应改为WHERE NOT EXISTS (SELECT 1 FROM logs WHERE logs.user_id = users.id AND logs.status = 'active')
别信经验，一定要看 EXPLAIN
同一语句在 MySQL 5.7 和 8.0 中可能走完全不同执行路径；统计信息过期、max_allowed_packet 设置、甚至临时表引擎都会影响优化器决策。
-
IN和EXISTS在两个表数据量相当时，性能差异往往不明显 - 真正关键的是
EXPLAIN输出里的type（是否用了range或ref）、rows（预估扫描行数）、Extra（是否出现Using temporary或Using filesort） - 如果子查询本身含聚合或复杂计算，先考虑是否能拆成中间表或物化视图，而不是纠结
IN还是EXISTS
最容易被忽略的点是：相关子查询（带外层字段引用）几乎总是更适合 EXISTS；而非相关子查询（独立执行）且结果集明确小于 500 行时，IN 更直观也更稳——但这个“500”不是魔法数字，得结合你的 innodb_buffer_pool_size 和实际 EXPLAIN 结果来定。
