LEFT SEMI JOIN 能避免重复行是因为它仅保留左表中存在右表匹配的行且每行最多输出一次，不返回右表字段，语义级去重无需 DISTINCT；MySQL 中可用 EXISTS 安全替代，IN 需警惕 NULL 导致漏数据。
LEFT SEMI JOIN 为什么能避免重复行
因为 LEFT SEMI JOIN 不是真正意义上的连接，它只保留左表中「存在右表匹配」的行，且每行最多出现一次——无论右表有多少条匹配记录，左表该行只输出一次。这和 INNER JOIN 的语义本质不同：INNER JOIN 返回所有匹配组合，一旦右表某 seller_id 出现多次，左表对应行就会被复制多次。
典型翻车场景：用 INNER JOIN 筛选“在商户白名单里的订单”，但白名单表 B 里 seller_id 有重复（比如人工误导入两次），结果订单表 A 中同一笔订单被查出两遍。
- LEFT SEMI JOIN 是语义级去重，不依赖
DISTINCT或聚合，开销更低 - 它不返回右表任何字段，所以不会因右表字段差异导致逻辑重复（比如
log_time不同） - 在 Hive/Spark SQL 中原生支持；MySQL 不直接支持该语法，但优化器会把符合条件的
IN子查询自动转为 semi-join 执行
MySQL 中替代 LEFT SEMI JOIN 的写法及陷阱
MySQL 没有 LEFT SEMI JOIN 关键字，但可以用 EXISTS 或 IN 实现等效语义。两者行为接近，但关键细节决定是否真能避免重复：
-
EXISTS更稳妥：SELECT * FROM A WHERE EXISTS (SELECT 1 FROM B WHERE B.seller_id = A.seller_id)—— 子查询只判真假，天然无视右表重复 -
IN要小心 NULL：SELECT * FROM A WHERE A.seller_id IN (SELECT seller_id FROM B)—— 若B.seller_id含NULL，整个条件变UNKNOWN，该行被过滤掉（不是重复，而是漏数据） - 若右表需加过滤条件（如只取状态为
'active'的商户），必须写进子查询里：WHERE B.seller_id = A.seller_id AND B.status = 'active'，不能挪到主查询后面 - 确保
B.seller_id有索引，否则EXISTS退化为嵌套循环全表扫描，比 JOIN 还慢
多字段匹配时只能用 SEMI JOIN 语义，不能靠 IN
当筛选条件需要多个字段共同决定（比如同时匹配 seller_id 和 region_code），IN 语法无法表达，EXISTS 成为唯一可靠选择：
SELECT * FROM orders o
WHERE EXISTS (
SELECT 1 FROM merchant_whitelist mw
WHERE mw.seller_id = o.seller_id
AND mw.region_code = o.region_code
AND mw.is_approved = 1
);而 IN ((o.seller_id, o.region_code)) 在 MySQL 中不合法，在 PostgreSQL 中虽支持但性能差、可读性低；INNER JOIN 则必然引入重复风险——只要白名单里同一 (seller_id, region_code) 对出现两次，订单就翻倍。
- 多列关联时，
EXISTS的 WHERE 条件就是天然的 semi-join 逻辑 - 别试图用
JOIN + GROUP BY去重：先膨胀再收缩，中间结果可能极大，内存和 IO 压力陡增 - Hive/Spark 用户可直接写
LEFT SEMI JOIN，但注意字段名作用域：右表字段不能出现在 SELECT 列表中
容易被忽略的执行计划验证点
写了 EXISTS 或 IN，不代表 MySQL 真按 semi-join 执行。必须看 EXPLAIN 输出中的 select_type 和 Extra 字段：
- 如果
select_type是DEPENDENT SUBQUERY，说明是相关子查询，但未必走 semi-join 优化 - 关键指标是
Extra出现Using semijoin或FirstMatch(o)、LooseScan等字样，才确认启用了 semi-join 策略 - 若
Extra写着Using where; Using index却没提 semijoin，可能因子查询含GROUP BY、ORDER BY或LIMIT导致优化器弃用 semi-join - MySQL 5.6+ 默认启用 semi-join，但可通过
SET optimizer_switch='semijoin=off'关闭——线上环境别乱动
真正起作用的不是语法糖，而是优化器是否识别出“只需判断存在性”这个意图。字段重复、NULL、子查询结构松散，都会让这个意图失效。
