EXISTS比IN更适合主表小、子查询表大的场景，因EXISTS找到首匹配即退出，而IN需全量生成结果集；子查询须关联且字段有索引，否则易全表扫描。
MySQL 中 EXISTS 为什么比 IN 更适合大表关联
当主表小、子查询表大时，EXISTS 通常更快——它只关心“是否存在匹配行”，找到第一个就短路退出；而 IN 可能被迫全量生成子查询结果集再做哈希查找，内存和时间开销都高。
- 适用场景：
SELECT * FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE customers.id = orders.customer_id AND customers.status = 'active') -
SELECT 1是惯用写法，不是真要查数据；用SELECT *或SELECT id也行，但语义不清且可能触发额外字段解析 - 子查询里必须有相关条件（如
customers.id = orders.customer_id），否则变成非关联子查询，逻辑就错了 - 如果子查询表没在关联字段上建索引，
EXISTS的优势会大幅缩水，甚至更慢
写错 EXISTS 子查询导致全表扫描的典型表现
执行计划里看到 type: ALL 或 rows 值极大，基本就是子查询没走索引。常见原因是相关条件写错位置或用了函数包裹。
- 错误写法：
EXISTS (SELECT 1 FROM logs WHERE DATE(log_time) = '2024-01-01')——DATE()让log_time索引失效 - 正确写法：
EXISTS (SELECT 1 FROM logs WHERE log_time >= '2024-01-01' AND log_time - 别在子查询的
WHERE里漏掉主表字段引用，比如写成WHERE customers.status = 'active'却没连orders，那就成了固定条件扫描 - 用
EXPLAIN看Extra列：出现Using where; Using index是理想状态；若只有Using where，说明没走覆盖索引
NOT EXISTS 替代 LEFT JOIN ... IS NULL 的边界情况
两者语义等价，但优化器处理方式不同。NOT EXISTS 在某些 MySQL 版本（尤其是 5.7 之前）更容易被误判为“无法使用索引”，而 LEFT JOIN 写法反而稳定。
- 安全写法：
SELECT o.* FROM orders o WHERE NOT EXISTS (SELECT 1 FROM returns r WHERE r.order_id = o.id) - 如果
returns.order_id有NULL值，NOT EXISTS不受影响，但LEFT JOIN ... IS NULL仍正确——这点常被忽略 - MySQL 8.0+ 对
NOT EXISTS优化已改善，但遇到性能抖动时，先检查执行计划里子查询是否走了索引，再考虑换写法 - 别在
NOT EXISTS子查询里加LIMIT 1，语法错误，MySQL 不支持
关联子查询里最麻烦的其实是嵌套层级和索引可见性——外层字段传进内层后，优化器不一定能识别出可用索引，尤其跨多个 JOIN 时。与其反复调参，不如先把子查询单独跑一遍 EXPLAIN，确认它自己能不能高效执行。
