DISTINCT不是数学意义上的“集合去重”，而是**结果集行级去重**——它只保证最终 SELECT 出来的每一行，在指定列组合上完全不重复，不改变原始数据结构，也不做集合运算（如交/并/补）。
为什么 DISTINCT 不等于集合操作？
MySQL 的
DISTINCT是一个查询修饰符，作用于
SELECT的输出结果，而非对底层表做集合抽象。它不会： - 自动排序（除非你显式加
ORDER BY） - 保证返回哪一行（当多行内容在去重列上相同时，MySQL 随机取其一） - 支持像
UNION那样隐式去重合并多个结果集（
UNION默认带
DISTINCT，但那是另一层语义）
DISTINCT 多列去重的常见误解
很多人以为
SELECT DISTINCT a, b FROM t是分别对
a和
b单独去重，其实它是对 **(a, b) 这个元组组合** 做唯一性判断：
SELECT DISTINCT department, job_title FROM employees;
✅ 正确理解：只保留 department+job_title 完全相同的行中的一条 ❌ 错误理解：“先去重 department，再在每个 department 内去重 job_title”
常见踩坑点： -
SELECT DISTINCT name, id FROM user→ 返回的是 name 和 id 都相同的整行才去重，不是“每个 name 只取一条” - 想按
name去重但还要带
id？
DISTINCT无法满足，必须用
GROUP BY name或窗口函数 -
SELECT id, DISTINCT name FROM user→ 直接报错，
DISTINCT必须紧贴
SELECT后，且不能插在字段中间
什么时候该换用 GROUP BY？
当你需要“去重 + 附带控制逻辑”时，
DISTINCT就力不从心了： 要保留每个
name对应的最小
id：
SELECT MIN(id) AS id, name FROM user GROUP BY name;要统计每个去重分组的出现次数：
SELECT name, COUNT(*) FROM user GROUP BY name HAVING COUNT(*) > 1;配合索引优化时：
GROUP BY在覆盖索引下有时比
DISTINCT更易走索引（尤其 MySQL 8.0+ 优化器对两者等价转换更成熟，但实测仍建议
EXPLAIN ANALYZE验证）
真正要注意的，不是“DISTINCT 算不算集合”，而是它只解决最轻量级的去重需求；一旦涉及保留哪条、怎么选、要不要计数、是否依赖顺序，就得跳出
DISTINCT思维，转向
GROUP BY或窗口函数。
