前几天跟一个刚入行的朋友聊天，他问我：“我写SQL时，经常遇到重复数据，用DISTINCT就能搞定，但这玩意儿到底怎么用才不坑？”我笑了笑，这问题问得挺实在。DISTINCT这个关键字看着简单，但用不好，轻则结果不对，重则性能崩盘。今天咱们就来唠唠这个“去重神器”的正确打开方式。
先说说DISTINCT最基础的用法。比如你有个订单表，想看看有哪些不同的客户在下单，直接写 就能拿到唯一客户列表。这听起来挺美好，但有个坑很多人踩过——当你加其他字段时，比如 ，去重就不是只对customerid了，而是对customerid和orderdate的组合去重。这意味着，同一个客户如果在不同日期下单，这些记录都会被保留，根本不是你想要的“唯一客户”。所以，DISTINCT作用的是整行数据，不是单个字段。想精准去重，要么只选必要字段，要么用 GROUP BY 加聚合函数。
再聊聊 DISTINCT 和 GROUP BY 的恩怨情仇。很多新手觉得两者差不多，都能去重，但实际场景里差别很大。比如你想统计每个城市的客户数，用 ，就能拿到精确数字。但如果直接用 ，只能得到城市列表，统计不了数量。GROUP BY 更适合做分组聚合，DISTINCT 更适合获取简单的唯一值。不过，当数据量很大时，DISTINCT 的排序去重机制可能比 GROUP BY 更耗资源。我见过一个案例，业务方用 DISTINCT 查几百万行的用户ID，跑了快两分钟，换成带索引的 GROUP BY 后，秒出结果。所以，别迷信 DISTINCT，它只是工具，不是万能钥匙。
说到性能，DISTINCT 的代价很多人低估了。数据库在执行 DISTINCT 时，会对结果集进行排序或哈希去重，这个过程需要消耗大量内存和 CPU。如果在大表上不加限制地使用 DISTINCT，比如 ，等于让数据库把整个表读一遍再排序去重——这操作比全表扫描还可怕。我亲眼见过一个系统因为这种查询直接卡死，DBA 紧急 kill 进程才恢复。优化思路很简单：第一，尽量缩小结果集，比如先 WHERE 过滤再 DISTINCT；第二，在去重字段上建索引，让数据库能快速定位唯一值；第三，考虑用 EXISTS 或 IN 子查询替代，有时更高效。记住，DISTINCT 不是不能用，但要用在刀刃上。
一个常见的场景是数据清洗。比如你从不同源导入数据，里面可能有重复记录，用 DISTINCT 可以快速去重。但这里有个细节：重复的定义可能很微妙。比如两个客户记录，名字相同但地址不同，算不算重复？如果简单用 ，地址不同的记录会被合并，地址信息就丢了。这时你得想清楚业务逻辑：是以 name 为准去重，还是以 name+address 组合为准？如果要以 name 为准保留一条记录，不如用 ROWNUMBER() 窗口函数，按某种规则排序后保留第一条。DISTINCT 在这里太粗暴，容易误删有效数据。所以，去重前先问自己：我要去的是哪种重复？是全字段重复，还是部分字段重复？
另一个容易被忽视的点是 NULL 值的处理。在 DISTINCT 眼里，所有 NULL 值被视为相等，多个 NULL 行会被合并成一行。这符合 SQL 标准，但有时会误导人。比如你查用户表里不同的邮箱地址，很多用户可能没填邮箱，字段为 NULL。DISTINCT 会把所有 NULL 合并成一个，结果集里只有一个 NULL，看起来好像只有一个用户没填邮箱，实际可能有几十个。如果你需要知道具体有多少个不同邮箱地址，包括 NULL 的情况，DISTINCT 没问题；但如果只想统计非空邮箱的唯一数量，得加个 。NULL 这个小妖精在 DISTINCT 里容易隐身，得留个心眼。
说到实践中的坑，还有一点：DISTINCT 和 ORDER BY 的配合。如果你用 DISTINCT 去重，又想在 ORDER BY 里使用不在 SELECT 中的字段，很多数据库会报错。比如 ，在 MySQL 里直接报错，因为 DISTINCT 去重后，age 可能对应多个值，排序规则不明确。解决办法要么把 age 加到 SELECT 里（但去重逻辑会改变），要么用子查询先排序再去重（但性能更差）。更干净的做法是用窗口函数：，这样既能去重，又能按 age 排序取一条。DISTINCT 在复杂排序面前，显得有点“直男”。
我想聊聊 DISTINCT 背后的哲学。它本质上是数据库在帮你做数据规整，但任何自动化去重都有代价。写 SQL 时，得想清楚：真的需要去重吗？还是数据本身就有问题？如果数据源设计得好，主键、唯一约束一上，重复根本不会出现。用 DISTINCT 去重，往往是在给低质量数据擦屁股。我见过一个团队，表里没加任何约束，所有查询都靠 DISTINCT 兜底，结果数据量一上来，系统直接崩了。他们花了两周时间优化数据模型，才解决根本问题。所以，DISTINCT 是急救包，不是日常保健品。下次写 SQL 前，先想想这重复能不能从源头避免；如果不能，再用 DISTINCT。毕竟，最好的去重，是数据压根不需要去重。
