使用DISTINCT去除完全重复行，或用GROUP BY分组聚合实现去重并统计；复杂场景可通过窗口函数如ROW_NUMBER()精准控制保留记录，同时结合索引优化与执行计划分析提升性能。

在 SQL 的

SELECT

语句中处理重复数据，核心思路无非是两种：要么直接剔除完全相同的行，要么通过某种分组聚合的方式来选择或计算出我们想要的那一份。这通常依赖于

DISTINCT

关键字或是

GROUP BY

子句，当然，更复杂的场景还会用到窗口函数。

解决方案

当我们需要从

SELECT

语句的结果集中移除重复行时，最直接的方式是使用

DISTINCT

关键字。它会检查所有选定的列，如果发现某一行与另一行的所有列值都完全相同，那么只会保留其中一条。

例如，假设我们有一个

orders

表，里面记录了顾客的购买记录，我们只想知道有哪些不同的顾客 ID 下过订单：

SELECT DISTINCT customer_id FROM orders;

这很简单，也很好理解。但如果我们的需求更复杂一点，比如想知道每个顾客 ID 下单的总金额，或者想在有重复记录时，只保留最新的一条，这时

DISTINCT

就显得有些力不从心了。

这时候，

GROUP BY

子句就派上用场了。它允许我们根据一个或多个列对数据进行分组，然后对每个组应用聚合函数（如

COUNT

,

SUM

,

AVG

,

MAX

,

MIN

）。虽然

GROUP BY

的主要目的是聚合，但它在某种程度上也能达到“去重”的效果，因为每个分组只会返回一行结果。

比如，我想知道有哪些不同的产品被购买过，并且每个产品被购买了多少次：

SELECT product_id, COUNT(order_id) AS total_orders FROM order_items GROUP BY product_id;

这里

product_id

实际上就是去重了，因为每个

product_id

只会出现在结果集的一行中，并带上它的聚合信息。

DISTINCT 与 GROUP BY，究竟何时选用？

这真的是个老生常谈的问题，但每次遇到，我都会忍不住多想几秒。从我的经验来看，选择

DISTINCT

还是

GROUP BY

，往往取决于你对“重复”的定义，以及你除了去重之外，是否还需要对数据进行聚合计算。

DISTINCT

是最直接的“去重”工具，它的语义非常清晰：给我所有列组合都唯一的行。如果你只是想知道某个列（或多列组合）有哪些唯一值，并且不需要任何额外的聚合操作，那么

DISTINCT

是最简洁、最符合直觉的选择。比如，你只想列出所有不同的城市名，或者所有不同的用户-设备组合，

SELECT DISTINCT city FROM users;

或者

SELECT DISTINCT user_id, device_id FROM sessions;

这样的语句就足够了。它的执行计划通常也比较简单，数据库会进行排序或哈希操作来识别并移除重复项。

而

GROUP BY

呢，它的核心功能是“分组聚合”。虽然它能间接实现去重，但它的真正威力在于，在去重的同时，还能对每个组进行统计分析。你可能想知道每个部门有多少员工，或者每个产品线的销售总额。这时候，

GROUP BY department_id

然后

COUNT(employee_id)

或者

SUM(sales_amount)

就成了必然。如果你只是用

GROUP BY

来去重，而没有使用任何聚合函数，比如

SELECT column1 FROM table GROUP BY column1;

，这在逻辑上与

SELECT DISTINCT column1 FROM table;

效果是等同的。但性能上，它们可能会有细微差别，通常

DISTINCT

会更优化一点，因为它不需要额外为聚合函数预留处理逻辑。

一个常见的误区是，有人会为了去重而强制使用

GROUP BY

，即便没有聚合需求。这通常是多此一举。反之，如果你在

SELECT

列表中包含了非

GROUP BY

列，但又没有对其使用聚合函数，数据库就会报错，因为它不知道如何处理这些在组内可能存在多值的数据。所以，记住这个原则：

DISTINCT

纯粹去重；

GROUP BY

分组并聚合，顺便去重。

除了去重，如何更精细地识别和分析重复数据？

有时候，我们不仅仅是想简单地把重复数据移除，我们可能还想知道哪些数据是重复的，重复了多少次，甚至在重复数据中，我们想保留“最好”的那一条，比如最新的、最大的，或者根据某种业务逻辑选择。这时候，窗口函数（Window Functions）就成了我们的利器，尤其是

ROW_NUMBER()

、

RANK()

、

DENSE_RANK()

和

COUNT() OVER()

。

以

ROW_NUMBER()

为例，它能为分区内（

PARTITION BY

）的每一行分配一个唯一的序列号，这个序列号是基于你定义的排序规则（

ORDER BY

）生成的。这使得我们能够非常精确地控制在重复数据中保留哪一条。

假设我们有一个

transactions

表，其中可能因为系统故障或其他原因，同一个用户在短时间内产生了多条几乎完全相同的交易记录，我们只想保留最新的一条。

百度文心百中

百度大模型语义搜索体验中心

23

查看详情

WITH RankedTransactions AS (     SELECT         transaction_id,         user_id,         transaction_amount,         transaction_timestamp,         ROW_NUMBER() OVER (PARTITION BY user_id, transaction_amount ORDER BY transaction_timestamp DESC) AS rn     FROM         transactions ) SELECT     transaction_id,     user_id,     transaction_amount,     transaction_timestamp FROM     RankedTransactions WHERE     rn = 1;

这里，我们根据

user_id

和

transaction_amount

进行分区，然后按

transaction_timestamp

倒序排序。这样，每个用户-金额组合中，最新的一条记录就会得到

rn=1

。最后，我们只需筛选出

rn=1

的记录，就实现了“保留最新重复数据”的需求。

如果你想知道哪些数据是重复的，并且重复了多少次，

COUNT(*) OVER()

也是个好帮手：

SELECT     user_id,     email,     COUNT(*) OVER (PARTITION BY user_id, email) AS duplicate_count FROM     users WHERE     COUNT(*) OVER (PARTITION BY user_id, email) > 1;

这段代码会找出

user_id

和

email

都相同的重复记录，并显示它们重复的次数。这种方式对于数据质量分析和清洗非常有用，它能帮助我们识别问题源头，而不仅仅是简单地删除。

处理重复数据时，有哪些潜在的性能陷阱和优化策略？

处理重复数据，尤其是在大规模数据集上，性能问题是不可避免的挑战。我见过不少因为去重操作导致查询慢如蜗牛的案例，往往都是因为对数据量和底层机制的理解不够深入。

一个常见的陷阱是，对非常大的表使用

DISTINCT

或

GROUP BY

而没有合适的索引。当数据库需要对数百万甚至数十亿行数据进行去重时，它通常需要将数据全部读入内存（如果内存足够）或临时磁盘空间，然后进行排序或哈希处理。这个过程会消耗大量的 I/O 和 CPU 资源。如果

DISTINCT

或

GROUP BY

的列上没有索引，或者索引不完整，数据库就不得不进行全表扫描，这无疑是性能杀手。

优化策略：

1. 建立合适的索引：这是最基本也是最重要的优化手段。如果你经常对

   customer_id

   进行

   DISTINCT

   操作，那么在

   customer_id

   列上建立索引是必须的。对于

   GROUP BY

   ，在

   GROUP BY

   子句中涉及的列上建立复合索引，可以显著提升性能。索引能够帮助数据库更快地定位和排序数据，减少全表扫描。

2. 选择性去重：如果你的表非常大，但你只需要去重其中一小部分数据，可以考虑先通过

   WHERE

   子句过滤数据，再进行去重。比如，只去重过去一个月的数据，而不是整个历史数据。这样可以大大减少需要处理的数据量。

3. 考虑数据类型：对

   VARCHAR

   类型的大文本字段进行

   DISTINCT

   或

   GROUP BY

   操作，比对

   INT

   或

   DATE

   类型字段的开销要大得多。因为字符串比较和哈希计算更复杂。如果可能，尽量将需要去重的字段转换为更高效的数据类型。

4. 分批处理：对于特别大的数据集，如果允许，可以考虑将数据分批导入临时表，在临时表中去重后再合并。虽然这增加了操作步骤，但有时能有效避免单次大查询造成的资源耗尽。

5. 理解执行计划：当你发现去重查询很慢时，务必查看数据库的执行计划（

   EXPLAIN

   或

   EXPLAIN ANALYZE

   ）。执行计划会告诉你数据库是如何处理你的查询的，是进行了全表扫描，使用了索引，还是创建了临时表。通过分析执行计划，你可以发现瓶颈所在，并有针对性地进行优化。比如，如果看到大量的

   Using temporary

   或

   Using filesort

   ，这通常意味着数据库在进行磁盘排序，此时可能需要优化索引或调整内存配置。

6. 利用数据库特性：一些数据库系统提供了特定的功能或优化器提示，可以帮助处理重复数据。例如，PostgreSQL 的

   LATERAL JOIN

   或 SQL Server 的

   appLY

   操作在某些复杂去重场景下可能提供更灵活高效的方案。

总而言之，处理重复数据并非一蹴而就，它需要我们对 SQL 语句的理解，对数据结构的把握，以及对数据库性能的洞察。没有银弹，只有根据具体场景，灵活运用各种工具和策略。