SQL如何去除查询结果重复值？使用DISTINCT关键字过滤

SQL去重，你真的会用DISTINCT吗？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

说到SQL查询结果去重，DISTINCT关键字往往是第一个跳入脑海的工具。它用起来简单直接，但你是否真正了解它的行为边界？今天就来聊聊，这个看似简单的关键字背后，那些容易被忽略的细节和陷阱。

SELECT DISTINCT 能去重，但只对整行生效

这里有个常见的误解：很多人下意识地认为DISTINCT是按查询中的某一个字段来去重的。其实不然，它的作用范围是整个SELECT列表。数据库会比较返回的每一行所有列的值，只有所有值都完全一致的两行，才会被视作重复并合并为一行。

举个例子：SELECT DISTINCT name, age FROM users。如果结果里有两行都是(“张三”, 25)，那么它们会被合并；但如果另一行是(“张三”, 26)，即便name字段相同，也会被保留——因为整行数据并不重复。

这就引出了几个关键点：

• 想按单字段去重，同时取出其他关联字段？ 单独的DISTINCT就力不从心了，通常需要借助GROUP BY或窗口函数来实现。
• DISTINCT不能附加条件。 比如，你无法实现“只对状态为1的记录进行去重”。正确的做法是先通过WHERE子句过滤，再使用DISTINCT。
• 性能考量。 从实现机制上看，DISTINCT本质上是一种隐式的GROUP BY操作。在处理大数据集时，它可能会触发临时表的创建或文件排序，需要留意其对查询性能的影响。

DISTINCT 和 GROUP BY 去重效果一样吗？

在纯粹为了去除重复行的场景下，SELECT DISTINCT a, b FROM t和SELECT a, b FROM t GROUP BY a, b返回的结果集通常看起来是一样的。但是，它们的语义和约束存在本质区别：

• 语义不同： DISTINCT是对结果集的操作，只关心行是否重复，不涉及聚合逻辑；而GROUP BY是明确的分组操作，分组后可以配合MAX()、COUNT()等聚合函数使用。
• 约束不同： 假设你写了SELECT DISTINCT a, b, c FROM t，其中列c在业务逻辑上其实依赖于列a（例如c是a的描述信息）。在某些数据库的严格模式下（如MySQL 5.7及以上版本），这可能会引发错误，因为c既不在DISTINCT的判定键中，也没有被聚合函数处理。
• 特殊语法： 值得一提的是，PostgreSQL提供了DISTINCT ON (column)语法，可以实现“按某一列去重，并返回每个组的第一行”。这虽然是DISTINCT功能的扩展，但并非标准SQL，在其他数据库中无法直接使用。

去重后还要取最新/最全的一条记录，DISTINCT 不行

这是业务中非常典型的需求：例如，需要为每个用户只保留一条记录，并且要的是他们最近注册的那一条。面对这种“按某字段分组，再按另一字段排序取首行”的需求，DISTINCT就完全无能为力了，因为它根本不支持排序逻辑。

此时，窗口函数才是更优雅和强大的解决方案：

SELECT user_id, email, created_at
FROM (
  SELECT user_id, email, created_at,
         ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
  FROM users
) ranked
WHERE rn = 1;

• 为什么用ROW_NUMBER()？ 相比RANK()，它能确保为每一行分配唯一的序号，避免了因并列排名而导致一个分组内取出多条记录的情况。
• 数据库支持： MySQL 8.0+、PostgreSQL、SQL Server、Oracle等主流数据库都已支持窗口函数。对于更早版本的MySQL，则需要使用自连接或用户变量来模拟实现。
• 核心逻辑： 关键在于理解PARTITION BY和ORDER BY的作用——PARTITION BY指定了去重的维度（按谁分组），而ORDER BY则决定了在每个组内，哪一条记录是你想要的“第一行”。

DISTINCT 在 JOIN 后容易误用导致结果膨胀或缩水

在多表关联查询后，发现结果行数异常，随手套上一个DISTINCT来“修复”，这是很多开发者都踩过的坑。这种做法往往治标不治本，甚至可能掩盖更严重的数据逻辑问题：

• 数据丢失： 如果主表中的一行记录，在关联表中对应多行（典型的一对多关系），直接使用DISTINCT会强行将这些多行合并成一行，导致关联表的细节信息丢失。
• 掩盖错误： 反过来，如果JOIN的条件写得不严谨（比如漏掉了关键关联字段），可能会产生大量的笛卡尔积，导致结果集异常膨胀。此时加上DISTINCT，可能会让结果行数看起来“正常”，但实际上数据关联关系已经是错误的。
• 诊断方法： 更稳妥的做法是，先仔细检查JOIN的逻辑是否正确。一个有效的验证技巧是，分别查询COUNT(*)（总行数）和COUNT(DISTINCT 主表主键)（去重后的主表记录数），对比两者是否一致，从而判断是否存在非预期的一对多关联膨胀。

总而言之，DISTINCT并非万能胶。尤其在涉及多表关联、复杂排序或特定业务规则时，它往往只是问题的表象。真正要解决的，是厘清数据之间的内在关系和业务语义。下次使用DISTINCT前，不妨多问一句：这真的是重复数据，还是我的查询逻辑需要调整？