EXISTS与INNER JOIN语义根本不同：EXISTS仅判断存在性，保证主表每行至多出现一次；INNER JOIN进行行组合，会因一对多关系放大结果集，导致重复行、更高IO和内存开销。
EXISTS 和 INNER JOIN 语义完全不同
EXISTS 是布尔判断，只关心“有没有匹配行”；INNER JOIN 是行组合，会把所有匹配的右表行和左表行拼成新行。这是根本差异，不是写法偏好问题。
常见错误是把 WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id) 直接替换成 INNER JOIN orders o ON o.user_id = u.id，结果用户列表翻倍甚至爆炸——因为一个用户有 5 条订单，就会在结果里出现 5 次。
- EXISTS 保证主表（如
users）每行最多出现一次 - INNER JOIN 可能放大主表行数，放大倍数 = 右表匹配行数
- 若业务只需过滤（如“查有订单的用户”），用 JOIN 就多花了 IO、内存、网络带宽
性能差异主要来自执行路径和资源消耗
EXISTS 走半连接（semi-join），找到第一条匹配就短路；INNER JOIN 默认要物化全部匹配组合。当右表匹配行多、或外层表大时，JOIN 中间结果集可能暴涨。
比如查“近 7 天有下单的商品”，商品表 50 万行，订单表日增百万行：
– EXISTS 对每个商品 ID，在订单表索引上做一次点查，最快 0.9 秒
– INNER JOIN 会先生成所有匹配对（可能几百万行），再去重或截断，实测慢 4 倍以上
- 索引缺失时，EXISTS 退化为全表扫描，但 JOIN 也一样糟，甚至更差（因需维护连接状态）
- MySQL 5.7 对驱动表选择不智能：若小表在右、大表在左，可能被迫嵌套循环，而非哈希连接
- PostgreSQL 和 SQL Server 的优化器常能把简单 EXISTS 自动改写为半连接，但 JOIN 写法无法反向压缩
什么时候必须用 INNER JOIN，不能用 EXISTS
当你需要右表的字段、或要做聚合、或要处理一对多关系时，EXISTS 无能为力。
例如：
– 要取订单时间、金额：SELECT u.name, o.order_date, o.amount FROM users u INNER JOIN orders o ON u.id = o.user_id
– 要统计每个用户的订单数：SELECT u.id, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id
- LEFT JOIN + IS NULL 可模拟
NOT EXISTS，但语法更绕，且无法直接带出右表字段 - EXISTS 子查询里写
SELECT 1或SELECT *没区别，现代数据库都忽略 SELECT 列表 - 别在 EXISTS 里加
ORDER BY或LIMIT（MySQL 8.0+ 允许但语义已变，Oracle 直接报错）
NULL 值对 EXISTS 和 INNER JOIN 的影响不同
EXISTS 完全不受 NULL 影响——它只看子查询是否返回行；INNER JOIN 的 ON 条件遇到 NULL 时，按 SQL 三值逻辑自动判为 FALSE，该行被丢弃，这点和 EXISTS 表现一致。
真正危险的是 IN/NOT IN：只要子查询返回任意 NULL，NOT IN 整个条件恒为 FALSE，而 NOT EXISTS 依然可靠。
- 所以“查没有订单的用户”，要用
NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)，别用u.id NOT IN (SELECT user_id FROM orders) - INNER JOIN 本身不处理 NULL 逻辑，但它依赖的 ON 表达式如果含 NULL，匹配失败——这和 EXISTS 的“存在性”判断不在同一维度
- 容易被忽略的点：EXISTS 子查询中若引用了外层 NULL 值（如
o.user_id = u.id AND u.status IS NULL），仍能正常执行；但 IN 子查询里一旦user_id为 NULL，整条 IN 判定变成 UNKNOWN
