exists 不一定比 in 快，关键看子查询是否相关、结果集大小、索引覆盖和执行计划；相关子查询且内表大、关联字段有索引时 exists 更优；独立子查询且结果集小、外表字段有索引时 in 更合适。
EXISTS 不一定比 IN 快，盲目替换可能更慢；关键看子查询是否相关、结果集大小、索引覆盖和执行计划。
什么时候该用 EXISTS 而不是 IN
当子查询里明确引用了外部表字段（即“相关子查询”），且内部表（子查询涉及的表）数据量大、但关联字段有索引时，EXISTS 通常更优。它能利用索引快速短路验证，避免生成大临时结果集。
- 典型场景：
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid')——o.user_id有索引，users表行数中等，orders表很大 - 必须写关联条件，否则逻辑错误：
EXISTS (SELECT 1 FROM orders WHERE status = 'paid')会变成“只要 orders 里有一条 paid 订单，就返回所有 users” -
SELECT 1是惯用写法，比SELECT *或SELECT id更轻量，MySQL 会忽略列内容，只判是否有行
什么时候 IN 反而更合适
当子查询是独立的（不依赖外部表）、结果集很小（比如几百行以内），且外部表对应字段有索引时，IN 往往更快。此时 MySQL 可将子查询结果构建成哈希集合，再用索引快速匹配主表。
- 典型场景：
SELECT * FROM products WHERE category_id IN (SELECT id FROM categories WHERE type = 'digital')——categories表只有几十行，products.category_id有索引 - 注意：IN 子查询必须返回单列；多列或空结果集会导致语法错误或意外逻辑（如
NULL出现在结果中会使整个条件判为UNKNOWN） - 若子查询结果集超万行，内存临时表开销陡增，
type在EXPLAIN中可能出现ALL或Using temporary，性能断崖下跌
别信经验，一定要看 EXPLAIN
MySQL 5.7 和 8.0 的优化器对同一语句可能生成完全不同执行计划；统计信息不准、索引缺失、参数设置（如 optimizer_switch）都会影响选择。硬背“小表驱动大表”容易翻车。
- 重点观察
EXPLAIN输出中的：type（是否用到索引）、rows（预估扫描行数）、Extra（是否出现Using where; Using index或Using temporary; Using filesort） - 对比两个版本的执行计划：先跑
EXPLAIN FORMAT=TRADITIONAL，再加ANALYZE（MySQL 8.0+）看真实耗时 - 特别警惕
NOT IN：若子查询结果含NULL，整个条件恒为FALSE；而NOT EXISTS无此问题，且仍可走索引
最容易被忽略的细节
很多人改写时只换关键字，却漏掉子查询结构变化带来的隐性代价：比如把 IN 改成 EXISTS 后，子查询里没补上 WHERE 关联条件，导致逻辑完全错乱；或者在 EXISTS 里写了 SELECT *，虽不影响结果但徒增解析开销。
还有就是 NULL 处理——IN 遇到 NULL 会整体失效，而 EXISTS 完全不关心值内容，只看行是否存在。这点在涉及左连接后过滤、或字段允许为空的业务场景中，极易引发线上数据遗漏。
