EXISTS适合判断“有没有”，JOIN适合取“有哪些字段”；前者用于存在性检查（如“用户是否VIP”），只返回布尔值且不放大结果集，后者用于获取关联字段、聚合或保留空值，但一对多时会导致主表行重复。
EXISTS 适合判断“有没有”，JOIN 适合取“有哪些字段”
你写 SQL 是为了确认某条记录是否关联另一张表，还是为了把关联表的字段一起查出来？这个目的直接决定该用 EXISTS 还是 JOIN。
常见错误现象：用 JOIN 去实现“查有订单的用户”，结果因为订单表一对多，用户行被重复放大；或者用 EXISTS 想顺便拿到订单金额，发现根本取不到——EXISTS 只返回布尔值，不带任何数据。
- 只要判断存在性（比如“用户是否 VIP”、“商品是否上架过”），优先选
EXISTS - 需要关联字段（如
orders.amount、products.name）、做聚合、或保留空值（LEFT JOIN），必须用JOIN -
NOT EXISTS可替代LEFT JOIN ... IS NULL，但语义更直白；而NOT IN遇到子查询含NULL就全失效，千万别混用
EXISTS 子查询里必须写对关联条件，否则等于没写
看似只差一个字段，实际可能让整个查询变成全表扫描或恒真判断。
错误写法：WHERE EXISTS (SELECT 1 FROM orders WHERE status = 'paid') —— 这个子查询没和主表挂钩，数据库会为每一行都执行一次无条件扫描，等价于 WHERE TRUE。
正确写法：WHERE EXISTS (SELECT 1 FROM orders WHERE user_id = users.id AND status = 'paid') —— 关联字段 user_id = users.id 必须明确写出，且 orders.user_id 必须有索引。
- 漏写关联条件是线上最常踩的坑，上线前务必用
EXPLAIN看select_type是否为DEPENDENT SUBQUERY - 如果
EXPLAIN显示子查询的type是ALL或index，说明user_id缺少索引，性能会断崖式下跌 - MySQL 5.7+ 对
SELECT 1和SELECT *执行计划一致，但写SELECT 1更清晰，避免同事误读
JOIN 的一对多会让结果集膨胀，EXISTS 不会
当主表一行对应子表多行时，JOIN 会复制主表行，EXISTS 则始终只返回原行一次。
典型翻车场景：统计“每个部门下有多少员工”，却用了 departments LEFT JOIN employees 再 COUNT(*)，结果把部门数算成员工总数；而 EXISTS 天然规避这个问题。
- 若只需计数或布尔判断，用
EXISTS+COUNT(*)更安全 - 若要用
JOIN同时取员工姓名和部门名，必须加DISTINCT或用子查询去重，否则逻辑错误 - 大表
JOIN前先确认连接字段类型是否严格一致（比如INTvsVARCHAR），否则索引失效，退化成嵌套循环
别信经验，只信 EXPLAIN 的 rows 和 type
同一句 SQL 在不同实例、不同数据分布下，执行路径可能完全不同。所谓“小表驱动大表”在现代优化器里早已不是铁律。
真正关键的是 EXPLAIN 输出里的两个字段：type 和 rows。
-
type出现eq_ref或ref才算走了索引；ALL或index就是全扫，得立刻检查索引 -
rows表示预估扫描行数：对EXISTS来说，理想值是 1（点查）；对IN子查询来说，如果远超实际返回行数，大概率触发了物化临时表+全表匹配 - MySQL 8.0+ 可用
EXPLAIN FORMAT=JSON查看是否用了Semi-Join优化；PostgreSQL 用EXPLAIN ANALYZE看真实Index Scan耗时
最常被忽略的其实是关联条件漏写和 NULL 陷阱——前者让 EXISTS 变成恒真，后者让 IN 悄悄丢数据。上线前不跑 EXPLAIN，等于裸奔。
