一、DISTINCT 的代价：排序与哈希的双重消耗

DISTINCT 的工作原理，说白了就是两步：先把所有数据拉出来，再把重复的干掉。

数据库内部实现 DISTINCT 主要有三条路径。第一条是基于排序的去重：先对结果集按去重字段进行排序，再顺序扫描，跳过与前一行完全相同的记录。这条路径兼容性最好，但排序本身就是昂贵操作，尤其当数据量达到百万级别时，内存不够用还会落盘，性能断崖式下跌。第二条是基于哈希的去重：构建一个哈希表，以去重字段为键，首次遇到的行写入表中，后续重复的直接跳过。这条路径比排序快，但需要足够的内存支撑哈希表，一旦内存不足，效率同样会急剧恶化。第三条是利用索引的"隐式去重"：如果去重字段上恰好有唯一索引，优化器可能直接走索引扫描，天然跳过重复值。这是最理想的情况，但完全依赖索引设计，可遇不可求。

无论走哪条路，DISTINCT 的核心问题在于：它必须处理完整的结果集之后，才能开始去重。哪怕主表某个值在子表中出现了一百次，DISTINCT 也得先把这一百次全部扫描完，排序或建完哈希表，才能告诉你"这个值只需要保留一个"。这种"先全集后去重"的模式，在大数据量场景下，就是性能的头号杀手。

二、EXISTS 的杀手锏：短路评估

EXISTS 的语义完全不同。它不是对结果集去重，而是做"存在性判断"——只要找到一条匹配的记录，立刻返回真，后续数据一概不看。

这种"短路评估"特性，让 EXISTS 在去重场景中拥有了 DISTINCT 无法企及的优势。举个实际场景：你有一张部门表和一张员工表，员工表有上百万条记录，每个部门对应成百上千名员工。你想知道哪些部门是有员工的。

用 DISTINCT 的写法，数据库会先把部门表和员工表做关联，拉出所有匹配行，然后对部门字段排序或建哈希表去重。整个过程中，每个部门的重复记录都被完整读取了一遍。

用 EXISTS 的写法，数据库从部门表的第一行开始，拿着部门标识去员工表中查找，找到第一条匹配的员工记录就立刻停止，直接判定该部门"存在"，然后处理下一个部门。哪怕某个部门在员工表中有五千条记录，EXISTS 也只读第一条就收工。

根据实际执行计划的对比数据，在百万级数据量的测试中，DISTINCT 方案的逻辑读高达一万五千多次，而 EXISTS 方案仅需两千多次，降幅超过八成。查询时间从秒级直接压缩到毫秒级。这就是短路评估带来的碾压级优势。

更关键的是，EXISTS 的子查询中写 SELECT 1 还是 SELECT NULL，结果完全一样，因为值本身根本不被使用，存在性检查只依赖布尔返回。这也意味着 EXISTS 不会像 IN 子查询那样，先把所有结果收集到临时工作表中再进行匹配，省去了大量内存开销。

三、性能边界：EXISTS 什么时候会失灵？

说到这里，你可能觉得 EXISTS 就是银弹。但现实从来不是非黑即白。EXISTS 的性能优势有一个绝对前提：关联字段上必须有索引。

如果子表的关联字段没有索引，EXISTS 就会退化成全表扫描。优化器会对主表的每一行，都去子表中从头到尾扫一遍，寻找匹配。这种情况下，逻辑读总量和 IN 方案几乎没有差别，甚至因为相关子查询的额外开销而更慢。所以，在考虑用 EXISTS 替代 DISTINCT 之前，第一件事就是检查执行计划中的访问类型——如果看到的是全表扫描，先加索引再说。

第二个边界出现在子查询本身很重的时候。如果 EXISTS 的子查询中包含多表关联、聚合函数或窗口函数，那么每一次短路评估的单次成本就会很高。主表有多少行，子查询就要执行多少次，累积下来的开销可能远超一次 DISTINCT 的排序成本。遇到这种情况，更好的策略是用物化方式预计算：通过临时表或公共表表达式把子查询结果先算好，再用 EXISTS 去匹配，或者干脆换回 GROUP BY。

第三个边界是语义不匹配。EXISTS 解决的是"有没有"的问题，而 DISTINCT 解决的是"全部唯一值"的问题。如果你的业务需求是保留主表的所有记录，包括那些在子表中不存在的记录（也就是需要 NULL 匹配语义），那么 EXISTS 做不到。这时候应该改用外连接配合非空判断，同时务必给连接字段加上索引。

第四个边界是多对多关联场景。当一个主表记录对应子表大量记录，且多个主表记录之间存在交叉关联时，EXISTS 的逐行评估模式会导致大量重复的子查询执行。而 JOIN 配合 DISTINCT 虽然也有数据膨胀的问题，但在某些数据库优化器的处理下，整体效率反而更高。有实测数据显示，在双表多对多关联的场景中，IN 子查询的执行时间甚至优于 EXISTS，因为 IN 的子查询只执行一次，结果集缓存后统一匹配，避免了重复扫描。

四、GROUP BY：被低估的中间选项

在讨论去重方案时，很多人会忽略 GROUP BY。实际上，在不少数据库优化器眼中，DISTINCT 和 GROUP BY 的执行计划是等价的，甚至 GROUP BY 可以更好地利用索引。

GROUP BY 的优势在于灵活性。它不仅能去重，还能同时获取每组的聚合信息——比如每个部门的员工数量、每个用户的最新登录时间。当你的去重需求不只是"拿到唯一值"，而是"拿到唯一值的同时还想知道点别的"，GROUP BY 就是比 EXISTS 更自然的选择。

从性能角度看，如果去重字段上有索引，GROUP BY 往往能直接利用索引的有序性完成分组，避免额外的排序或哈希操作。而 DISTINCT 在相同条件下也能享受这个红利，但 EXISTS 则完全依赖关联字段的索引，对去重字段本身的索引利用率反而不如前两者。

所以，如果你的需求只是单纯去重、不涉及聚合，且关联字段有索引，EXISTS 是最优解。如果需要聚合信息，GROUP BY 更合适。如果既没索引又需要复杂逻辑，那可能需要重新审视查询设计本身。

五、实战中的决策框架

总结下来，选择 EXISTS 还是 DISTINCT，核心看三个问题。

第一，关联字段有没有索引？没有就先建索引，这是所有优化的起点。有索引，EXISTS 大概率胜出；没索引，两者半斤八两，甚至 EXISTS 更差。

第二，子查询重不重？如果子查询只是简单的等值匹配，EXISTS 的短路特性会发挥到极致。如果子查询本身包含复杂计算，考虑物化预计算或换用 GROUP BY。

第三，你要的是"存在性"还是"完整唯一集合"？如果只是判断"有没有"，EXISTS 天然适配。如果需要拿到所有不重复的完整记录，且主表中可能存在子表没有匹配的行，那就别硬套 EXISTS，老老实实用外连接或 GROUP BY。

还有一种容易被忽视的情况：当子查询结果集很大且稳定，比如"所有有效客户标识"这类相对固定的数据，又被多个查询反复引用时，最高效的方案既不是 EXISTS 也不是 DISTINCT，而是建一张物化视图或缓存表。每次查询直接查这张表，比任何子查询都省。

六、写在最后

EXISTS 替代 DISTINCT，本质上是用"存在性语义"替换了"集合去重语义"。前者天然去重、短路退出，后者必须全集扫描后再过滤。这个差异在小数据量时几乎无感，但在百万级数据的战场上，就是毫秒与秒级的分野。

但任何优化都有边界。EXISTS 不是万能钥匙，它的性能完全依赖索引质量、子查询复杂度和业务语义的匹配程度。真正成熟的工程师，不会迷信某一种方案，而是根据数据规模、索引状态和查询目的，在 EXISTS、DISTINCT、GROUP BY 甚至物化视图之间，找到那个最精确的平衡点。

数据库优化的艺术，从来不在于记住多少技巧，而在于知道每种技巧的边界在哪里。知道边界，才能在边界之内，把性能榨干。