distinct用于查询时去除重复行，作用于select的所有列组合而非单列，语法为select distinct column from table；2. group by通过分组实现去重，常与聚合函数结合使用，适用于需要统计的场景，而单纯去重时distinct更直观；3. 使用distinct时常见误区包括误以为只对首列生效、忽略其不影响原始数据、性能在大数据量下可能下降及null值被视为相同；4. 其他去重方法包括使用row_number()窗口函数按分区和排序保留指定记录，适用于需保留最新或最优重复项的场景；5. 自连接或exists可用于识别重复数据，而创建唯一索引是从源头防止重复的根本手段。选择方法应根据具体需求权衡。
当我们在SQL里想要把重复的数据筛掉，只看那些独一无二的值或行时，
DISTINCT无疑是最直接、最省心的办法。它就像一个过滤器，一下子就能帮你把那些碍眼的重复项清理掉，让你的查询结果变得干净利落。
说白了，用
DISTINCT去重，语法上简单到不能再简单。你只需要在
SELECT后面，紧跟着你想要去重的列名前面加上
DISTINCT这个关键词就行。
比如，如果你想看看一个
users表里都有哪些不重复的城市：
SELECT DISTINCT city FROM users;
这样，不管
users表里有多少用户住在同一个城市，结果只会显示一次那个城市的名字。
要是你想看的是不重复的组合呢？比如，一个用户表里，我们想找出所有独一无二的“姓名和邮箱”的组合：
SELECT DISTINCT first_name, email FROM users;
这里有个很多人刚开始会误解的地方：
DISTINCT它不是只作用于
first_name，而是作用于
first_name和
first_name和
DISTINCT给过滤掉。如果名字一样但邮箱不同，或者邮箱一样但名字不同，那它们都会被视为不同的行保留下来。这在我看来，是
DISTINCT最核心也最容易被忽略的细节。它操作的是“行”的唯一性，而不是单个字段。
DISTINCT和GROUP BY在去重上的区别是什么？
提到去重，很多人自然而然会想到
GROUP BY。这俩哥们儿确实都能达到“去重”的效果，但它们的出发点和侧重点完全不一样。
DISTINCT嘛，就像我们刚才说的，它的主要任务就是“过滤”——把查询结果里完全重复的行或指定列的组合给剔除掉，只保留一份。它就是个纯粹的去重工具，简单粗暴，直奔主题。
而
GROUP BY呢，它更像是一个“分类汇总”的工具。它的核心目的是把数据按照你指定的列进行分组，然后你通常会结合聚合函数（比如
COUNT()、
SUM()、
AVG()等）来对每个组进行计算。在分组的过程中，因为每个组的键（也就是你
GROUP BY的列）是唯一的，所以它也就间接地实现了去重效果。
举个例子，你想知道每个城市有多少用户：
SELECT city, COUNT(*) FROM users GROUP BY city;
这里
city自然是去重了，因为每个城市只会有一个分组。但它的重点是
COUNT(*)，是统计。如果你只是想知道有哪些城市，不用
COUNT(*)，只写
SELECT city FROM users GROUP BY city;，效果和
SELECT DISTINCT city FROM users;是一样的。
所以，我个人习惯是，如果我只是想看“有哪些不重复的值”，不带任何聚合计算，那
DISTINCT是我的首选，因为它意图更明确，写起来也更直接。但如果我的需求是“按某个维度分组，并对每组数据做些统计”，那
GROUP BY才是正解。有时候，为了性能或者更复杂的逻辑，你甚至会发现
GROUP BY在某些场景下比
DISTINCT表现更好，但这往往是更深层次的优化问题了。
使用DISTINCT时有哪些常见的“坑”或误解？
虽然
DISTINCT用起来很方便，但它也有几个容易让人踩坑的地方，或者说，是一些常见的误解。
一个最常见的误解就是，有人觉得
DISTINCT只会作用于它后面紧跟着的第一个列。比如
SELECT DISTINCT col1, col2 FROM table;，他们可能以为只有
col1会去重，
col2还是会显示所有值。但正如我前面强调的，
DISTINCT作用的是所有你
SELECT出来的列的组合。只有当
col1和
col2的组合完全一样时，那一行才会被视为重复。如果
col1相同但
col2不同，那这依然是两条不同的记录。这点一定要牢记，不然结果可能和你预期的完全不一样。
再来，
DISTINCT只影响你的查询结果集，它并不会真的修改数据库里的原始数据。它只是在数据被检索出来展示给你的时候，做了一个临时的过滤。如果你想从根本上清除表里的重复数据，那需要用
DELETE语句结合其他技术，比如
ROW_NUMBER()或者创建唯一索引。
性能方面，当你的表非常大，或者
DISTINCT的列上有大量不同值时，
DISTINCT操作可能会比较慢。因为它需要对数据进行排序或者使用哈希表来识别和消除重复项。这在处理海量数据时，可能会成为一个瓶颈。所以，在生产环境中，对于超大数据量，我们可能需要考虑更复杂的优化，比如建立合适的索引，或者在ETL过程中提前去重。
还有一个小细节，就是
NULL值的处理。在
DISTINCT看来，所有的
NULL值都是相等的。所以，如果你有一列包含多个
NULL，
DISTINCT只会保留一个
NULL。这在处理数据清洗时，尤其需要注意。
除了DISTINCT，还有哪些SQL方法可以实现数据去重？它们各自适用于什么场景？
DISTINCT固然好用，但SQL的工具箱里还有不少其他去重的好手，它们在不同的场景下能发挥更大的作用，尤其当你需要更精细的控制，或者不仅仅是简单地去重时。
我个人最常用，也觉得最强大的，就是窗口函数ROW_NUMBER()
配合PARTITION BY
。这个方法简直是去重界的瑞士军刀，尤其当你需要保留“最新”或“最优”的那条重复记录时，它简直是完美。
基本思路是这样的：你先用
PARTITION BY把数据按照你认为的“重复”维度（比如用户ID）进行分组，然后在每个组内，用
ORDER BY给每条记录排个序（比如按创建时间倒序，最新的排第一）。
ROW_NUMBER()就会给每组的第一条记录一个
1，第二条一个
2，以此类推。然后你只需要筛选出
ROW_NUMBER() = 1的那些记录，就只保留了每个分组里你想要的那一条。
WITH RankedData AS (
SELECT
*,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) as rn
FROM
user_logins
)
SELECT
user_id, login_time, ip_address -- 选择你需要的列
FROM
RankedData
WHERE
rn = 1;这个方法在需要从一堆重复数据中，智能地选择保留哪一条时，简直无敌。比如，一个用户可能有多条登录记录，但你只关心他最近的一次登录。
此外，如果你是想找出哪些数据是重复的，而不是直接去重，你还可以用自连接（Self-Join）或者EXISTS
子句。
比如，找出
users表里名字完全相同的用户：
SELECT t1.* FROM users t1 JOIN users t2 ON t1.first_name = t2.first_name AND t1.id <> t2.id;
这种方法更多是用于“发现”重复，而不是“消除”重复。
最后，从预防的角度讲，创建唯一索引（CREATE UNIQUE INDEX
）是防止重复数据进入数据库的根本方法。它直接在数据库层面设置了约束，确保某些列或列的组合永远不会出现重复值。当然，这是一个DDL操作，是数据建模的一部分，而不是查询时的去重技巧。但从“如何处理重复数据”的宏观角度看，它是最有效且一劳永逸的方案。
总的来说，
DISTINCT是查询时快速去重的利器，简单直接；
ROW_NUMBER()是更精细、更智能的去重选择，尤其适用于需要保留特定重复项的场景；而唯一索引则是从源头杜绝重复的防线。选择哪种方法，完全取决于你的具体需求和数据场景。没有最好的，只有最适合的。
