半连接不能用INNER JOIN直接实现，因其会因右表重复键导致左表行重复输出，违背“每行仅出现一次”语义；应使用EXISTS进行存在性判断，高效且语义准确。
半连接不能用 INNER JOIN 直接实现，它本质是“存在性判断”，不是“组合匹配”。真要高效、语义准确地做半连接，就该用 EXISTS，而不是硬套 JOIN 或迷信 IN。
为什么不能用 INNER JOIN 做半连接
INNER JOIN 会把左表每一行和右表所有匹配行拼成新行，一旦右表有重复键（比如多个订单对应同一客户），左表那条客户记录就会被复制多遍——这违背半连接“每行只出现一次”的核心要求。业务上查“有订单的客户”，结果里不该出现同一个客户三行。
常见错误现象：
• 查询返回客户数量远超实际客户数
• 加了 DISTINCT 才对，但代价是额外排序或哈希去重
• 执行计划里出现 Hash Join 或 Merge Join，而非优化器本可选的 Hash Semi Join
- 强行用
INNER JOIN+DISTINCT是绕路，不是半连接 - 若右表无索引，
JOIN还可能触发全表嵌套扫描，比子查询更慢 - 某些数据库（如 SQL Server）对
INNER JOIN结果集默认不自动去重，逻辑风险明确
IN 子句的典型陷阱与适用边界
IN 看似简单，但实际执行时容易掉坑：子查询一出 NULL，整行就被静默过滤；子查询若带 DISTINCT、GROUP BY 或复杂表达式，优化器大概率放弃半连接优化，退化为物化临时表 + 哈希查找。
错误写法示例：WHERE id IN (SELECT DISTINCT customer_id FROM orders WHERE status = 'paid')
这里 DISTINCT 让优化器难以估算结果集大小，常导致计划变差。
-
IN只适合右端是静态小列表（如IN (1, 5, 8)）或关联小码表（如状态字典表） - 若右表字段无索引，
IN子查询仍会全表扫描，和EXISTS一样慢 - MySQL 5.7+ 虽支持
IN半连接优化，但前提是子查询不能含LIMIT、UNION、聚合函数等禁用结构
EXISTS 是更可靠、更可控的半连接写法
EXISTS 天然适配半连接语义：不取字段、不处理 NULL、支持谓词下推、执行器能尽早终止扫描。只要子查询中正确关联外层表，优化器基本都能识别为半连接场景，并倾向选择 Nested Loop Semi Join 或 Hash Semi Join。
标准写法：SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id)
-
SELECT 1是惯用写法，明确告诉优化器“只判存在，别读数据” - 必须写关联条件（如
o.customer_id = c.id），否则变成非相关子查询，结果恒为真或假 - 右表的
customer_id字段要有索引，否则即使写EXISTS，也大概率走全表扫描 - PostgreSQL 中，有索引时
EXISTS常走Index Scan+Nested Loop，内存占用远低于IN的物化路径
执行计划验证与调优关键点
写了 EXISTS 不等于就触发了半连接优化。最终是否走 Semi Join，取决于统计信息、索引、以及子查询结构是否“干净”。别跳过验证这步。
检查方法（以 PostgreSQL 为例）：EXPLAIN (ANALYZE, BUFFERS) SELECT ... EXISTS ...
重点看输出里有没有 Semi Join、Hash Semi Join 或 Nested Loop Semi Join 字样。
- 若没看到
Semi关键字，先跑ANALYZE orders更新统计信息 - 子查询里避免
SELECT *、ORDER BY、LIMIT—— 这些都会干扰优化器判断 - SQL Server 中，
EXISTS默认生成Semi Join计划；而IN在子查询含NULL时可能退化为Apply或临时表计划 - 真正影响性能的，从来不是
IN还是EXISTS的语法选择，而是右表连接字段有没有索引、索引选择性高不高
最容易被忽略的一点：半连接优化不是“写了就生效”，它高度依赖优化器对子查询结构的识别能力。哪怕你手写的是 EXISTS，只要子查询里混进了 OR 条件、标量子查询、或者跨 schema 引用，优化器就可能放弃半连接策略——这时候得靠执行计划说话，而不是凭经验猜。
