使用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表，其中可能因为系统故障或其他原因，同一个用户在短时间内产生了多条几乎完全相同的交易记录，我们只想保留最新的一条。
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和
处理重复数据时，有哪些潜在的性能陷阱和优化策略？
处理重复数据，尤其是在大规模数据集上，性能问题是不可避免的挑战。我见过不少因为去重操作导致查询慢如蜗牛的案例，往往都是因为对数据量和底层机制的理解不够深入。
一个常见的陷阱是，对非常大的表使用
DISTINCT或
GROUP BY而没有合适的索引。当数据库需要对数百万甚至数十亿行数据进行去重时，它通常需要将数据全部读入内存（如果内存足够）或临时磁盘空间，然后进行排序或哈希处理。这个过程会消耗大量的 I/O 和 CPU 资源。如果
DISTINCT或
GROUP BY的列上没有索引，或者索引不完整，数据库就不得不进行全表扫描，这无疑是性能杀手。
优化策略：
建立合适的索引：这是最基本也是最重要的优化手段。如果你经常对
customer_id
进行DISTINCT
操作，那么在customer_id
列上建立索引是必须的。对于GROUP BY
，在GROUP BY
子句中涉及的列上建立复合索引，可以显著提升性能。索引能够帮助数据库更快地定位和排序数据，减少全表扫描。选择性去重：如果你的表非常大，但你只需要去重其中一小部分数据，可以考虑先通过
WHERE
子句过滤数据，再进行去重。比如，只去重过去一个月的数据，而不是整个历史数据。这样可以大大减少需要处理的数据量。考虑数据类型：对
VARCHAR
类型的大文本字段进行DISTINCT
或GROUP BY
操作，比对INT
或DATE
类型字段的开销要大得多。因为字符串比较和哈希计算更复杂。如果可能，尽量将需要去重的字段转换为更高效的数据类型。分批处理：对于特别大的数据集，如果允许，可以考虑将数据分批导入临时表，在临时表中去重后再合并。虽然这增加了操作步骤，但有时能有效避免单次大查询造成的资源耗尽。
理解执行计划：当你发现去重查询很慢时，务必查看数据库的执行计划（
EXPLAIN
或EXPLAIN ANALYZE
）。执行计划会告诉你数据库是如何处理你的查询的，是进行了全表扫描，使用了索引，还是创建了临时表。通过分析执行计划，你可以发现瓶颈所在，并有针对性地进行优化。比如，如果看到大量的Using temporary
或Using filesort
，这通常意味着数据库在进行磁盘排序，此时可能需要优化索引或调整内存配置。利用数据库特性：一些数据库系统提供了特定的功能或优化器提示，可以帮助处理重复数据。例如，PostgreSQL 的
LATERAL JOIN
或 SQL Server 的APPLY
操作在某些复杂去重场景下可能提供更灵活高效的方案。
总而言之，处理重复数据并非一蹴而就，它需要我们对 SQL 语句的理解，对数据结构的把握，以及对数据库性能的洞察。没有银弹，只有根据具体场景，灵活运用各种工具和策略。
