在数据库管理和开发过程中，我们经常会遇到一个令人头疼的问题：重复数据。无论是因为人为录入错误、应用程序的 Bug，还是系统间的数据同步问题，重复行都会像杂草一样在数据库中滋生。这不仅会浪费宝贵的存储空间，更可怕的是，它会导致我们的查询结果不准确，报表数据失真，甚至在某些情况下严重影响查询性能。
想象一下，当你试图统计公司有多少员工时，因为数据重复，你发现“张三”出现了三次。这不仅尴尬，更可能导致错误的业务决策。因此，作为专业的开发者或数据库管理员，掌握如何优雅、高效地清理重复数据，是一项必不可少的实战技能。
在这篇文章中，我们将深入探讨 SQL 中处理重复行的艺术。我们将不仅学习如何“识别”它们，更重要的是，我将向你展示 5 种经得起实战考验的方法 来彻底“删除”它们。我们会从基础的方法入手，逐步深入到使用窗口函数等高级技巧，并详细分析每种方法的适用场景和性能考量。让我们开始这场数据清理之旅吧！
准备工作：搭建演示环境
为了让你能够直观地看到每一条 SQL 语句的效果，我们需要先建立一个演示场景。假设我们正在管理一个简单的员工表 Employees，由于之前的导入操作失误，里面包含了一些重复的记录。
首先，让我们执行以下代码来创建并填充这张表。请注意，我们在其中特意插入了几组数据（例如“李雷”和“韩梅梅”），它们的名字和部门完全相同，这就是我们需要清理的“重复数据”。
-- 创建 Employees 表
CREATE TABLE Employees (
EmployeeID INT PRIMARY KEY,
Name VARCHAR(100),
Department VARCHAR(100),
Salary DECIMAL(10, 2)
);
-- 插入演示数据（包含重复行）
-- 注意：Name 为 ‘Li Lei‘ 和 ‘Han Meimei‘ 的记录出现了多次
INSERT INTO Employees VALUES
(1, ‘Li Lei‘, ‘IT‘, 8000),
(2, ‘Han Meimei‘, ‘HR‘, 7000),
(3, ‘Li Lei‘, ‘IT‘, 8000), -- 重复数据
(4, ‘Han Meimei‘, ‘HR‘, 7000), -- 重复数据
(5, ‘Jim Green‘, ‘Sales‘, 6000),
(6, ‘Li Lei‘, ‘IT‘, 8000); -- 重复数据
-- 查看当前数据状态
SELECT * FROM Employees;
执行上述查询后，你会看到表中存在明显的冗余。接下来，我们将学习如何精准地找出这些“害群之马”。
第一步：识别重复行
在动手删除之前，我们必须先确认“谁”是重复的。这是数据清洗中最关键的一步，因为如果不小心，我们可能会误删有价值的数据。
在 SQL 中，最常用的“侦查”手段是结合使用 INLINECODE9149dd36 子句和 INLINECODE8e1ee8ae 子句。这就像是在给数据分组点名，看看哪个名字被叫了多次。
-- 查找在姓名和部门上存在重复的记录
SELECT
Name,
Department,
COUNT(*) as DuplicateCount
FROM Employees
GROUP BY Name, Department
HAVING COUNT(*) > 1;
代码解析：
-
GROUP BY Name, Department: 告诉数据库按照“姓名”和“部门”这两个维度将数据分成不同的篮子。在这个例子中，我们认为只要这两个字段相同，就是同一个人。 -
COUNT(*): 计算每个篮子里有多少行数据。 -
HAVING COUNT(*) > 1: 这就像是一个过滤器，它只把那些“人数超过 1”的篮子（即存在重复的组）挑出来显示。
通过这条查询，我们就能明确知道：哦，原来 IT 部门的 Li Lei 出现了 3 次，HR 部门的 Han Meimei 出现了 2 次。 识别出目标后，我们就可以动手清理了。
—
方法 1：使用子查询与 MIN (或 MAX) 函数
这是最传统、也是最通用的方法之一。它的核心逻辑是：保留每组重复数据中 ID 最小（或最大）的那一行，删除其余的。
这个方法非常好理解：既然每条记录都有一个唯一标识符（如 EmployeeID），我们可以找出每个分组中最小的 ID，然后告诉数据库：“把所有 ID 不在这个最小 ID 列表里的记录都删掉”。
-- 删除重复行，保留每组中 ID 最小的一行
DELETE FROM Employees
WHERE EmployeeID NOT IN (
-- 子查询：找出每个重复分组中，ID 最小的那个记录
SELECT MIN(EmployeeID)
FROM Employees
GROUP BY Name, Department
);
-- 验证结果：重复行已被移除
SELECT * FROM Employees;
这种方法优点很明显：逻辑清晰，标准 SQL 支持，几乎所有数据库（MySQL, PostgreSQL, SQL Server, Oracle）都能跑。
但需要注意：如果你表中数据量非常大，INLINECODEe9c5ce68 有时候会导致性能问题，因为它可能导致全表扫描。此外，如果 INLINECODEe1a7cd7b 本身有 NULL 值，处理起来需要额外小心（因为 NULL NOT IN NULL 的结果通常也是 NULL）。不过在我们的场景中，ID 是主键，所以非常安全。
—
方法 2：使用 ROW_NUMBER() 窗口函数 (推荐)
如果你使用的是现代版本的 SQL Server、Oracle 或 PostgreSQL（MySQL 8.0+ 也支持），这是我最推荐的方法。它不仅强大，而且非常灵活。
ROW_NUMBER() 是一个窗口函数，它可以为每一行数据生成一个序号。神奇的是，我们可以指定它按照什么规则“分组”和“排序”。
-- 使用 CTE (公用表表达式) 配合 ROW_NUMBER()
;WITH CTE AS (
SELECT
EmployeeID,
Name,
Department,
-- 按照 Name 和 Department 分组，组内按 ID 排序并生成行号
ROW_NUMBER() OVER (
PARTITION BY Name, Department
ORDER BY EmployeeID ASC
) AS RowNum
FROM Employees
)
-- 删除行号大于 1 的记录（即重复的记录）
DELETE FROM CTE
WHERE RowNum > 1;
深入理解代码：
- INLINECODE1c0716f7: 这相当于前面提到的 INLINECODE10e94688。它重置了计数器，确保每个不同的员工组合都有自己独立的编号序列（从 1 开始）。
-
ORDER BY EmployeeID ASC: 决定了谁是第一。这里我们设定 ID 最小的排第 1。 -
WHERE RowNum > 1: 既然排名 1 的我们要保留，那么排名 2、3、4 的自然就是多余的重复数据，直接删除。
为什么我推荐这种方法？
因为它给了我们极大的控制权。假设你的需求变了，不是保留“ID 最小”的，而是保留“工资最高”的那条记录，你只需要修改 ORDER BY Salary DESC 即可，其他逻辑完全不用变。这种可读性和灵活性在处理复杂去重时非常有价值。
—
方法 3：巧用临时表 (安全第一)
在生产环境中，有些 DBA（数据库管理员）非常谨慎，不敢直接在原表上执行 DELETE 操作，生怕万一手抖删错了。这时候，“临时表”大法就是最好的选择。
这种方法的思路是：创建一个干净的房间，把整理好的数据搬进去，然后把旧房间清空，再把数据搬回来。 虽然步骤多一点，但它非常安全，且在处理超大数据量时，有时能避免锁表过久。
-- 第一步：创建一个临时表，并将去重后的数据存入其中
CREATE TEMPORARY TABLE TempEmployees AS
SELECT *
FROM Employees
-- 这里的逻辑确保我们只取每个分组的第一条数据
WHERE EmployeeID IN (
SELECT MIN(EmployeeID)
FROM Employees
GROUP BY Name, Department
);
-- 第二步：清空原表（注意：这里比 DELETE 更快，且重置自增ID）
TRUNCATE TABLE Employees;
-- 第三步：将干净的数据从临时表插回原表
INSERT INTO Employees
SELECT * FROM TempEmployees;
-- 第四步：删除临时表，清理战场
DROP TEMPORARY TABLE TempEmployees;
-- 最终验证
SELECT * FROM Employees;
实战见解： 这种方法特别适合数据迁移或大清洗。如果原表有很多索引或触发器，INLINECODE35c79273 和 INLINECODE1f0ecb64 的组合可能比逐行 DELETE 效率更高。此外，你还可以在步骤 2 和步骤 3 之间对数据进行校验，确保万无一失后再插回。
—
方法 4：使用 DISTINCT 和 INSERT INTO (全表重建)
这是另一种“重置”思路的方法。它的核心在于利用 DISTINCT 关键字直接剔除重复项，然后重新生成表。
不过，这里有一个小技巧：如果直接在原表操作，可能会因为约束问题导致麻烦。所以更稳健的做法通常是创建一个新表，然后替换旧表。但为了演示，我们展示一种结合 CTE 的清理方式（逻辑上类似于方法 2，但更侧重于数据的“选择”）。
-- 注意：这种方法在 SQL Server 等数据库中非常有效
-- 步骤 A: 创建包含唯一数据的新表（或使用临时表结构）
-- 步骤 B: 使用 DISTINCT 筛选数据
SELECT DISTINCT Name, Department, MIN(Salary) as Salary -- 注意：如果有多个字段，DISTINCT 可能需要配合聚合函数
INTO UniqueEmployees
FROM Employees
GROUP BY Name, Department; -- 这里用 GROUP BY 往往比 DISTINCT 更好控制多列情况
-- 步骤 C: 删除旧表数据并插入新数据 (或者直接重命名表，这在生产环境更常见)
-- TRUNCATE TABLE Employees;
-- INSERT INTO Employees SELECT * FROM UniqueEmployees;
-- *为了演示一致性，这里展示一种更安全的“创建新表替换”思路的伪代码逻辑：
-- 1. SELECT * INTO Employees_Backup FROM Employees; (先备份！)
-- 2. DROP TABLE Employees;
-- 3. SELECT * INTO Employees FROM Employees_Backup GROUP BY ...;
需要警惕的地方： 使用 INLINECODE662cd6eb 时，如果表中有很多列（比如 10 列），但你只想根据其中 2 列（如 Name, Department）去重，INLINECODE47e2d572 会检查所有 10 列是否完全一致。如果“李雷”有一条记录工资是 8000，另一条是 8100，INLINECODE951af738 会认为它们是不同的行而全部保留！这就是为什么在复杂去重场景下，我更推荐 INLINECODE3dafd70c 或 INLINECODE892fd42a 而不是简单的 INLINECODEe8d61f97。
—
方法 5：利用 RANK() 或 DENSE_RANK() (处理并列情况)
既然我们聊到了窗口函数，不妨再多学一点。除了 INLINECODE33930397，还有 INLINECODE6963c37c 和 DENSE_RANK()。
-
ROW_NUMBER(): 不管数据是否完全一样，强制排序（1, 2, 3, 4）。 -
RANK(): 如果两个员工的工资完全一样，它们会并列第一，下一个名次会空出（1, 2, 2, 4）。
应用场景： 假如我们想保留重复数据中“工资最高”的员工，如果有两个人工资都是最高的，我们希望把他们都保留下来（只删工资低的重复项）。这时 INLINECODEd2ff483c 可能会随机删掉其中一个高薪员工，而 INLINECODEf069f001 能帮我们精准识别。
-- 使用 RANK() 来处理复杂的并列情况
;WITH CTE AS (
SELECT
EmployeeID,
Name,
Salary,
-- 按部门和姓名分组，工资高的排前面（Rank=1）
RANK() OVER (
PARTITION BY Name, Department
ORDER BY Salary DESC -- 工资降序
) AS SalaryRank
FROM Employees
)
DELETE FROM CTE
WHERE SalaryRank > 1; -- 删除那些工资不是最高（即排名靠后）的重复记录
这个技巧在处理具有业务权重的去重需求时非常实用，比简单的“保留第一条”要智能得多。
—
总结与最佳实践
我们在这次探索中看了好几种删除重复行的方法。你可能会问：“到底哪一种最适合我？”
作为经验丰富的开发者，我的建议是：
- 首选
ROW_NUMBER()：对于现代开发，它的可读性、灵活性和性能都是平衡得最好的。它能让你清晰地表达“我想保留谁”的业务逻辑。 - 备选 INLINECODE9b29d8d0 + INLINECODEbcede83b：如果你在使用老版本的数据库，或者写一个非常简单的脚本，这种方法永远不会出错，兼容性极强。
- 操作前必备份：无论你用什么方法，在生产环境执行
DELETE之前，请务必创建一份备份表！这是数据安全最重要的底线。 - 注意索引与性能：如果你的表有数百万行数据，直接删除可能会锁表很久，影响用户使用。这时考虑分批删除（如每次删 10000 行）或者使用临时表交换法会更稳妥。
写在最后
数据质量是系统的基石。虽然清理重复数据看起来是一件琐事，但掌握了这些 SQL 技巧，你就能从容应对各种数据混乱的场面。希望这篇文章不仅能帮你解决当下的 Bug，更能让你写出更优雅、更健壮的 SQL 语句。
下一次，当你再面对那堆乱糟糟的重复数据时，你不会感到头疼，而是会自信地微笑：“终于可以试试那个新学的窗口函数了！”
如果你有任何疑问，或者在实际操作中遇到了特殊的棘手案例，欢迎在评论区交流，我们一起探讨解决方案。