1. 从“查重”到“治重”一个数据工程师的日常在数据处理的日常里重复数据就像房间里散落的灰尘你永远不知道它什么时候会冒出来但一旦积累起来就会让整个系统运行不畅甚至导致决策失误。我处理过太多因为重复数据引发的“事故”报表总数对不上、用户收到多条相同的营销短信、库存数量莫名虚高……每一次排查最终都指向数据库里那些不该存在的“双胞胎”记录。MySQL作为最广泛使用的关系型数据库之一其SELECT语句的灵活性让我们有无数种方法找出这些重复项。但“找出”只是第一步更重要的是理解数据为何重复、如何精准定位、以及后续如何处理。今天我就结合自己踩过的坑和总结的经验把MySQL里查询重复数据这套“组合拳”拆解清楚。无论你是刚接触SQL的新手还是需要优化现有查重逻辑的老手这篇文章都能给你一套从原理到实战的完整方案。2. 理解重复数据的本质什么才算“重复”在动手写SQL之前我们必须先定义清楚在当前业务场景下什么才算重复数据这个定义直接决定了查询语句的写法。通常重复可以分为两大类2.1 完全重复记录这是最理想化的情况即两条或多条记录在所有字段上的值都完全相同。例如由于程序BUG或导入脚本重复执行导致同一用户信息被插入了两次。这种重复相对容易发现和处理。2.2 业务逻辑上的重复记录这才是实战中的常态和难点。记录并非所有字段都相同但在业务意义上它们代表了同一个实体。常见的场景包括自然键重复例如用户表username用户名或email邮箱应该唯一但出现了两个不同的user_id对应同一个邮箱。组合键重复例如订单明细表理论上order_id订单号和product_id产品ID的组合应该唯一但同一订单里同一个产品出现了两条明细。近似重复例如联系人表name字段为“张三丰”和“张三豐”繁体或因录入错误导致的“abcemail.com”和“abcemial.com”。这类问题通常需要结合模糊匹配或数据清洗流程不属于简单SQL查重的范畴但思考时需要意识到它的存在。一个关键的实操心得永远不要假设数据库里的数据是干净的。在编写查重SQL前最好与业务方或产品经理确认基于哪几个字段判断“重复”。这个判断标准就是GROUP BY子句和HAVING子句里的核心。3. 核心武器库GROUP BY 与 HAVING 的联合作战MySQL中查找重复数据核心思想是“分组计数”。我们利用GROUP BY将可能重复的记录聚合成一组然后用HAVING子句筛选出那些组内记录数大于1的组。HAVING与WHERE的区别在于WHERE在分组前过滤行而HAVING在分组后过滤组。3.1 基础查重找出所有重复值及其出现次数假设我们有一张用户表users我们认为email字段唯一现在要找出所有重复的邮箱。SELECT email, COUNT(*) AS duplicate_count FROM users GROUP BY email HAVING COUNT(*) 1 ORDER BY duplicate_count DESC;代码解读与注意事项GROUP BY email将所有email值相同的记录分到同一组。COUNT(*)计算每一组的记录总数。HAVING COUNT(*) 1只保留那些记录数大于1的组即重复的邮箱。ORDER BY duplicate_count DESC按重复次数降序排列让你一眼就能看到最严重的重复问题。这是最常用、也是最应该首先运行的语句。它能快速给你一个全局视图到底有多少个字段值重复了每个值重复了多少次3.2 进阶查重查看重复记录的完整明细只知道邮箱重复了还不够我们可能需要看到是哪些具体的用户记录导致了重复以便后续处理比如联系用户确认、执行删除。SELECT u.* FROM users u INNER JOIN ( SELECT email FROM users GROUP BY email HAVING COUNT(*) 1 ) AS dup ON u.email dup.email ORDER BY u.email, u.id; -- 建议按重复字段和主键排序便于查看为什么用子查询而不是直接WHERE IN上面的语句使用了一个派生表子查询dup来先找出所有重复的email值然后通过INNER JOIN回原表取出所有这些重复值对应的所有原始记录。这种方法在重复值不多时效率很高且逻辑清晰。你也可以用WHERE ... IN (...)子查询实现但JOIN的方式在复杂查询中通常更易读和优化。一个踩坑记录早期我习惯在HAVING子句里用COUNT(1)或COUNT(email)后来才明白在MySQL中对于COUNT(*)、COUNT(1)和COUNT(非空列)在性能上几乎没有区别因为优化器会做处理。但COUNT(column)会忽略该列为NULL的行。在查重场景下我们关心的是行数所以直接用COUNT(*)最准确、最无歧义。3.3 复合条件查重基于多个字段判断重复业务中更常见的是组合键重复。例如在订单商品表order_items中order_idproduct_id应该唯一。SELECT order_id, product_id, COUNT(*) AS duplicate_count, GROUP_CONCAT(id) AS duplicate_ids -- 将重复记录的主键列出便于后续处理 FROM order_items GROUP BY order_id, product_id HAVING COUNT(*) 1;这里引入了一个非常实用的函数GROUP_CONCAT()它可以将同一分组内某个字段的所有值连接成一个字符串。上面例子中我们把重复记录的主键id都拼接起来结果可能像“1001,1005”。这样你一眼就知道是哪两条具体的记录冲突了后续要删除或合并时可以直接操作这些ID。注意GROUP_CONCAT()的结果长度受系统变量group_concat_max_len限制默认1024字节。如果重复的记录非常多可能导致截断。在处理前可以通过SET SESSION group_concat_max_len 1000000;临时调大。4. 实战演练定位并清理重复数据的完整工作流找到了重复数据接下来怎么办直接DELETE吗不那太危险了。一个完整、安全的流程应该是这样的4.1 第一步确认与备份在任何删除操作之前务必将查出的重复数据导出或备份。你可以将上面INNER JOIN查询的结果插入到一张临时表或导出为CSV文件。-- 创建临时表存储重复记录明细 CREATE TABLE tmp_duplicate_users AS SELECT u.* FROM users u INNER JOIN ( SELECT email FROM users GROUP BY email HAVING COUNT(*) 1 ) dup ON u.email dup.email; -- 或者更简单地直接导出查询结果这一步是你的“后悔药”。如果清理操作出错你可以从这里恢复数据。4.2 第二步制定保留策略对于每组重复记录你需要决定保留哪一条。常见策略有保留最新的一条假设有created_at时间戳字段保留时间最大的。保留最旧的一条保留时间最小的。保留信息最完整的一条通过比较其他字段如电话号码、地址是否为空来决定。人工复核对于重要数据将列表交给业务人员确认。4.3 第三步编写精准删除语句以保留最新记录为例这是最需要谨慎的环节。我们的目标是删除每组重复记录中除了我们想保留的那条之外的所有记录。假设用户表users有id主键、email、created_at字段策略是保留每个邮箱最新创建created_at最大的记录。错误示范一种常见的误区-- 错误这会删除所有重复邮箱的记录一条不留 DELETE FROM users WHERE email IN ( SELECT email FROM users GROUP BY email HAVING COUNT(*) 1 );正确做法使用关联子查询或JOIN。这里提供两种经典写法。方法一使用关联子查询和NOT INDELETE FROM users WHERE id NOT IN ( SELECT MAX(id) -- 或 MIN(id) 取决于你想保留哪个 FROM users GROUP BY email HAVING COUNT(*) 1 ) AND email IN ( SELECT email FROM users GROUP BY email HAVING COUNT(*) 1 );解释先找出每个重复邮箱组里id最大的那条记录假设id与创建时间正相关然后删除那些email在重复列表中但id又不是组内最大的记录。注意在MySQL中直接对正在修改的表进行子查询有时会遇到问题可能需要用临时表或更复杂的JOIN。方法二使用自连接更通用、更推荐DELETE u1 FROM users u1 INNER JOIN users u2 ON u1.email u2.email AND u1.id u2.id WHERE u1.email IN ( SELECT email FROM (SELECT email FROM users GROUP BY email HAVING COUNT(*) 1) AS t );解释u1.id u2.id这个连接条件确保了对于同一邮箱的多条记录id较小的那条假设是旧记录会与id较大的记录连接上。这样u1就代表了所有需要被删除的“旧记录”。这种方法逻辑清晰且避免了在DELETE中直接使用原表的复杂子查询可能带来的语法或性能问题。一个至关重要的建议在执行DELETE前务必先将其改为SELECT *进行验证。例如把上面的DELETE u1改成SELECT u1.*看看选出来的记录是不是你真正想删除的那些。确认无误后再执行删除操作。4.4 第四步验证与添加约束清理完成后再次运行最初的查重SQL确认结果集为空。然后强烈建议为相关字段添加唯一约束从根源上杜绝未来的重复数据。-- 为users表的email字段添加唯一索引 ALTER TABLE users ADD UNIQUE INDEX idx_unique_email (email); -- 为order_items表添加联合唯一索引 ALTER TABLE order_items ADD UNIQUE INDEX idx_unique_order_product (order_id, product_id);添加唯一索引后任何尝试插入重复数据的操作都会导致数据库报错应用程序必须处理这个错误例如提示用户“邮箱已存在”从而保证数据的一致性。5. 应对大规模数据的性能优化策略当表的数据量达到百万、千万级时简单的GROUP BY全表扫描可能会非常慢。这时就需要一些优化技巧。5.1 为分组字段建立索引这是最有效的优化手段。如果经常需要按email查重那么为email字段建立一个普通索引或唯一索引如果业务允许将极大加速GROUP BY操作。CREATE INDEX idx_email ON users(email);有了这个索引数据库可以更快地完成分组和计数而不是进行全表扫描。5.2 分而治之分批处理如果表实在太大即使有索引单次查询也可能消耗过多资源。可以考虑按时间范围或其他维度分批查询。-- 假设按创建月份分批查重 SELECT email, COUNT(*) FROM users WHERE created_at BETWEEN 2024-01-01 AND 2024-01-31 GROUP BY email HAVING COUNT(*) 1;5.3 使用窗口函数进行高级分析MySQL 8.0如果你使用的是MySQL 8.0或更高版本窗口函数ROW_NUMBER()是处理重复数据的利器它能让“保留一条删除其余”的逻辑变得异常清晰。-- 找出所有重复记录并标记出行号 SELECT id, email, created_at, ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at DESC) AS row_num FROM users;在这个结果里对于每个email分区即重复组row_num 1的就是最新的一条记录。那么要删除旧记录逻辑就很简单了DELETE FROM users WHERE id IN ( SELECT id FROM ( SELECT id, ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at DESC) AS row_num FROM users ) AS t WHERE t.row_num 1 -- 选择行号大于1的即需要删除的旧记录 );注意MySQL要求对派生表子查询使用别名并且多层嵌套有时是必要的。窗口函数的写法在逻辑表达上比传统的自连接JOIN更加直观和强大。6. 特殊场景与边界情况处理6.1 处理NULL值在SQL中NULL不等于任何值包括它自己。因此GROUP BY时所有NULL值会被归为同一组。这可能是你想要的也可能不是。例如如果你在查找重复邮箱而有些记录的邮箱是NULL那么它们会被算作彼此重复。你需要根据业务逻辑决定是否在WHERE子句中排除NULL值。SELECT email, COUNT(*) FROM users WHERE email IS NOT NULL -- 排除NULL值只检查有邮箱的记录 GROUP BY email HAVING COUNT(*) 1;6.2 区分大小写与字符集MySQL的默认校对规则collation通常是不区分大小写的如utf8mb4_general_ci。这意味着‘ABCemail.com’和‘abcemail.com’在GROUP BY时会被认为是相同的。如果你的业务需要区分大小写需要在建表或查询时指定区分大小写的校对规则如utf8mb4_bin。-- 在查询时指定区分大小写 SELECT email, COUNT(*) FROM users GROUP BY email COLLATE utf8mb4_bin HAVING COUNT(*) 1;6.3 查询重复数据的衍生信息有时我们不仅想知道是否重复还想知道重复数据带来的业务影响。例如计算重复订单商品造成的金额统计错误。SELECT oi.order_id, oi.product_id, COUNT(*) as dup_count, SUM(oi.quantity) as total_dup_quantity, -- 重复商品的总数量 SUM(oi.quantity * oi.unit_price) as total_dup_amount -- 重复商品的总金额 FROM order_items oi GROUP BY oi.order_id, oi.product_id HAVING COUNT(*) 1;这个查询能直观地告诉你重复数据在业务指标上造成了多大的“水分”。查找重复数据的SQL本身并不复杂但其背后的数据质量意识和工作流程的严谨性才是区分新手和老手的关键。每一次查重都是一次对数据模型和业务流程的审视。我个人的习惯是对于核心业务表将简单的查重语句作为数据健康度巡检脚本的一部分定期运行将问题扼杀在萌芽状态。毕竟清理一万条历史重复数据远比防止一条新重复数据产生要麻烦得多。最后一个小技巧可以把这些常用的查重SQL保存成视图VIEW方便团队其他成员随时使用统一排查标准。