半连接不能直接用inner join，因其会返回所有匹配组合，导致左表行因右表重复键而被重复输出，违背“每行仅出现一次”的语义；而semi-join仅判断存在性并只输出左表记录。

为什么不能直接用 INNER JOIN 做半连接

半连接（semi-join）只关心左表中是否存在匹配的右表记录，不返回右表字段，也不放大左表行数。而 INNER JOIN 会返回所有匹配组合，一旦右表有重复键，左表对应行就会被重复输出——这违反了半连接语义。比如查“有订单的客户”，用 INNER JOIN 可能返回同一个客户多行，但业务上只需要客户ID出现一次。

IN 子句的写法与陷阱

IN 最直观：左表字段值是否出现在子查询结果集中。但它对 NULL 敏感，且子查询不能返回多列。

• 正确写法：SELECT * FROM customers WHERE id IN (SELECT customer_id FROM orders)
• 若 orders.customer_id 含 NULL，整个 IN 表达式结果为 UNKNOWN，对应行被过滤掉——这是标准 SQL 行为，但常被误认为“漏数据”
• 子查询若写成 SELECT customer_id, order_date FROM orders，会报错：ERROR: subquery must return only one column
• MySQL 5.7+ 和 PostgreSQL 对 IN 子查询做了物化优化，但若右表极大且无索引，仍可能慢于 EXISTS

EXISTS 子句更可靠的原因

EXISTS 检查子查询是否返回至少一行，天然忽略 NULL，语义更贴近半连接本意，且执行器通常能尽早终止扫描。

• 标准写法：SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id)
• 子查询中的 SELECT 1 是惯用写法，实际不读取数据，仅判断存在性；写 SELECT * 也没问题，但易误导他人以为要取字段
• 必须关联外层表（如 o.customer_id = c.id），否则变成非相关子查询，结果恒为真或假
• PostgreSQL 中，EXISTS 在右表有合适索引时，常走 Nested Loop + Index Scan，比 IN 的 Hash Semi Join 更省内存

性能差异和索引建议

两者逻辑等价，但执行计划可能不同。关键不在语法，而在右表连接字段是否有索引。

• 若 orders.customer_id 无索引，IN 和 EXISTS 都会触发全表扫描，差别不大
• 若有索引，EXISTS 在多数引擎中更容易利用索引下推（index condition pushdown），尤其当左表很大、右表匹配率低时
• SQL Server 中，EXISTS 默认生成 Semi Join 执行计划；而 IN 在子查询含 NULL 时可能退化为更复杂的计划
• 别忽略统计信息更新：ANALYZE orders（PostgreSQL）或 UPDATE STATISTICS（SQL Server）会影响优化器选择

实际写的时候，优先用 EXISTS，除非团队明确约定统一用 IN 且确认右表无 NULL。最易被忽略的是子查询里漏写关联条件，导致逻辑错误却不出错——这种 bug 很难通过测试覆盖。