如何处理SQL重复数据删除_巧用DISTINCT与GROUP BY语句
优先用 DISTINCT 去重;需聚合计算则必须用 GROUP BY;二者语义不同不可互换,混用易报错或漏数据;真正删重需用 DELETE 配合窗口函数或自连接。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新! 👉 点此立即查看 👈
重复数据到底该用 DISTINCT 还是 GROUP BY?
先说一个核心结论:如果只是想查询去重后的结果,优先用 DISTINCT;如果要对重复的数据组进行聚合计算,比如统计次数、取最新时间,那就必须用 GROUP BY。这两者背后的语义完全不同,不能随意互换,强行混用很容易导致数据遗漏或者直接报错。
一个常见的误区是,一看到“有重复”就下意识地加上 GROUP BY,却忘了写聚合函数。这在 MySQL 5.7+ 版本会直接抛出 ERROR 1055,而 PostgreSQL 和 SQL Server 的语法检查更严格,连执行的机会都不会给。
DISTINCT是行级去重,作用于整个SELECT列表,它比较的是所有选中字段的组合值是否完全相同。GROUP BY是分组操作,必须配合聚合函数(如COUNT()、MAX())使用,否则那些不在分组字段里的列,数据库根本不知道该取哪一行的值。- 从性能角度看,
DISTINCT通常比GROUP BY更轻量,尤其是在没有索引的字段上操作时,GROUP BY很可能会触发临时表和文件排序,拖慢查询速度。
用 GROUP BY 删除重复行时为什么不能只写 DELETE FROM t GROUP BY x?
原因很简单:标准 SQL 语法就不支持直接对 GROUP BY 的结果执行 DELETE 操作。虽然 MySQL 允许通过 DELETE ... JOIN 或子查询的方式变通实现,但写法一旦有误,后果很严重——要么删不干净,要么可能把数据全删光。
安全的做法是,先精准定位出每组中需要保留的那条记录(比如保留 id 最小的那条),再删除其余重复项。一个经典的写法是利用自连接:
DELETE t1 FROM users t1 INNER JOIN users t2 WHERE t1.email = t2.email AND t1.id > t2.id;
这个写法的精妙之处在于:
- 条件
t1.id > t2.id确保了只删除那些“ID更大”的重复行,从而为每组保留了id最小的那条记录。 - 务必为连接条件字段(如这里的
email)建立索引,否则面对大数据表时,多表全扫描会慢得让人无法忍受。 - 需要注意的是,SQLite 等数据库不支持这种
DELETE ... JOIN语法,得改用基于ROWID的子查询来实现。
DISTINCT 在多字段场景下容易误判“不重复”
DISTINCT 对 NULL 值的处理是个隐蔽的坑,常常被忽略。在大多数数据库中,NULL = NULL 的比较结果会是 false(未知),但 DISTINCT 却会把多个 NULL 视为相同的值进行合并。这可能导致一些本该保留的记录被错误地去除。
举个例子:SELECT DISTINCT name, phone FROM customer,如果表里有两行数据都是 (‘张三’, NULL),那么 DISTINCT 会把它们当成重复数据,只返回一条。但从业务角度看,我们可能希望保留所有电话为空的“张三”记录。
- 解决方法之一:使用
COALESCE(phone, CONCAT('null_', id))这类技巧,将NULL显式转换为可以相互区分的值。 - 更可控的方法是换用
GROUP BY配合ROW_NUMBER()窗口函数(前提是数据库支持),这样可以更精细地控制去重逻辑。 - 提醒一下:MySQL 8.0+、PostgreSQL、SQL Server 都支持窗口函数,但旧版本的 MySQL 就只能依靠变量来模拟实现了。
真正要“删除物理重复行”,别只盯着 DISTINCT 和 GROUP BY
必须明确一点:DISTINCT 和 GROUP BY 都只是查询层面的操作,不会改变原始表中的数据。真想从物理上删除重复行,必须动用 DELETE 语句,并配合子查询或 CTE(公共表表达式)。至于子查询里要不要用 DISTINCT 或 GROUP BY,完全取决于你如何定义“每组保留哪一条”。
目前最稳健且通用的方案(兼容 MySQL 8.0+ 和 PostgreSQL 等主流数据库)是利用窗口函数:
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY email ORDER BY updated_at DESC) rn FROM users ) DELETE FROM users WHERE id IN ( SELECT id FROM ranked WHERE rn > 1 );
这里的关键已经不是 DISTINCT 或 GROUP BY 了,而是通过 ROW_NUMBER() 窗口函数,明确指定了“在每个邮箱分组内,按更新时间倒序排列,只保留第一条”。在实际执行删除前,务必先用 SELECT 语句查看一下 ranked 这个 CTE 的结果,确认即将删除的数据完全符合预期。
对于不支持窗口函数的老版本 MySQL,就只能依赖更绕的自连接或临时表方案,逻辑复杂,出错概率也更高。有时候,花点时间升级数据库版本,可能比折腾几个小时调试复杂的 SQL 要划算得多。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
Oracle RAC如何检查归档模式?跨节点确认归档归属
Oracle RAC归档日志全面检查指南:节点级验证与线程归属深度解析 在Oracle RAC集群环境中,归档日志的配置与状态检查是一项需要精细化操作的关键任务。它要求数据库管理员必须对每个节点逐一进行归档模式、路径设置、日志生成状态的审查,并深刻理解日志线程归属的核心逻辑。检查的核心流程是:首先通
Oracle RMAN恢复时如何重命名日志文件_配置日志路径参数
解决RMAN恢复时日志文件名冲突引发的 ORA-01157 错误 在使用RMAN执行数据库恢复操作时,若目标磁盘上已存在同名的在线重做日志文件(例如 redo01 log),恢复进程常会中断并抛出 ORA-01157: cannot identify lock data file 错误。值得注意的是
SQL如何查询用户连续达标的天数_窗口函数状态机模型
SQL如何查询用户连续达标的天数:窗口函数状态机模型 说起查询“连续达标”天数,很多人的第一反应可能是用日期相减。但这里有个本质问题需要先想清楚:我们到底在识别什么? “连续达标”的本质是识别不间断的满足条件时间序列,需用LAG()判断状态延续性并用SUM() OVER构造段ID,而非依赖日期相减。
Redis List在多语言环境乱码问题_检查字符编码与序列化格式
Redis List 中文乱码:从根源到解决,一次讲透 遇到 Redis List 里中文显示乱码,这事儿确实让人头疼。但说到底,问题的核心就两点:要么是客户端编码没对齐,要么是序列化方式不匹配。想彻底解决,就得统一使用 UTF-8 编码、禁用自动解码、避免混用序列化,最后别忘了用 --raw 和
MongoDB为什么建议开启集群内部认证_防止节点被恶意替换或加入
开启集群内部认证是生产环境强制前提,keyFile为最轻量internal auth方式,需6–1024字节随机二进制数据、600权限,且mongos不支持该配置;启用后客户端须显式指定SCRAM-SHA-256及--authenticationDatabase admin。 将“开启集群内部认证”
- 日榜
- 周榜
- 月榜
1
2
3
4
5
6
7
8
9
10
相关攻略
2015-03-10 11:25
2015-03-10 11:05
2021-08-04 13:30
2015-03-10 11:22
2015-03-10 12:39
2022-05-16 18:57
2025-05-23 13:43
2025-05-23 14:01
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程
热门话题

