EXISTS 比 INNER JOIN + DISTINCT 更适合半连接，因其仅判断存在性、支持短路、避免去重开销与语义失真，且不受NULL影响；而后者需全量连接再去重，性能差、逻辑模糊。
EXISTS 为什么比 INNER JOIN + DISTINCT 更适合半连接
因为 EXISTS 只关心子查询是否返回至少一行，不实际取值、不产生重复行、不拖慢执行计划。而用 INNER JOIN 后加 DISTINCT，数据库必须先完成全部连接、生成中间结果集，再去重——数据量一大，内存和 CPU 开销直线上升，且可能因去重丢失语义（比如原意是“只要存在就满足”，但 DISTINCT 会强制合并逻辑上不同的行）。
-
EXISTS在找到第一条匹配后立即短路，多数引擎能利用索引快速终止扫描 -
INNER JOIN + DISTINCT无法短路，必须构建完整连接结果 - 当右表有重复关联键（如订单表对同一用户多条记录），
DISTINCT会掩盖原始基数，让业务逻辑变模糊
标准写法：用 EXISTS 替代 LEFT SEMI JOIN（无直接语法时）
MySQL / PostgreSQL / SQL Server 都不支持 SEMI JOIN 关键字，但可用 EXISTS 精确表达其语义。关键点是把“被驱动表”写进子查询的 WHERE 条件中，并与外层关联。
SELECT u.id, u.name
FROM users u
WHERE EXISTS (
SELECT 1
FROM orders o
WHERE o.user_id = u.id
AND o.status = 'paid'
);
- 子查询里用
SELECT 1而非SELECT *，避免列解析开销 - 关联条件必须写在子查询的
WHERE中，不能只靠JOIN；否则优化器可能误判为普通连接 - 若需过滤子表数据（如只查已支付订单），条件必须放在子查询内，而非主查询的
AND后——否则会变成先连接再过滤，失去半连接意义
常见翻车点：EXISTS 里写错关联或漏索引
最常出现的错误不是语法错，而是语义错或性能崩。典型现象是查询突然变慢十倍，或者结果比预期多/少。
- 把
u.id = o.user_id写成u.id = o.id—— 外键搞反，导致子查询恒真或恒假 - 子查询里没加
WHERE关联条件，变成无关联子查询（correlated subquery 变成 uncorrelated），结果全表扫描或恒为 TRUE/FALSE -
orders(user_id)缺少索引，EXISTS就退化为嵌套循环全表扫描，比JOIN还慢 - 误在主查询加
AND o.status = 'paid'（o在主查询不可见），报错Unknown column 'o.status'
和 IN 对比：什么时候该选 EXISTS 而不是 IN
当子查询可能返回 NULL，或左表远大于右表时，EXISTS 更稳更快。
-
IN (SELECT ...)遇到子查询含NULL时，整个条件变为UNKNOWN，该行被过滤掉——这往往不是你想要的；EXISTS不受NULL影响 - 子查询结果集大（比如几万行），
IN可能触发临时表或哈希构建；EXISTS仍保持索引驱动+短路 - 若右表很小且确定无
NULL，IN可读性略高；但只要有一丝不确定性，优先写EXISTS
半连接本质是“存在性判断”，不是“集合成员判断”——这个边界一旦模糊，后面加索引、调执行计划都救不回来。
