DISTINCT是对SELECT后所有字段的完整组合去重，而非单列筛选；它只判断元组是否完全相同，不保证行序或业务逻辑选取，需用GROUP BY或窗口函数实现“每组取一条”需求。
DISTINCT 本质是组合去重，不是按单列“筛掉重复值”。它只对 SELECT 后面所有字段的**完整组合**做唯一性判断。写错字段顺序、漏加索引、误以为能保留“某一行代表”，都会导致结果不符合预期。
DISTINCT 多列去重时，到底在去什么？
很多人写 SELECT DISTINCT user_id, amount FROM orders，本意是“每个用户只取一条订单”，但实际效果是：只要 user_id 和 amount 的组合不同，就算两条记录。比如用户 A 有金额为 100 和 200 的两笔订单，这两行都会被保留。
这是因为 DISTINCT 不关心“哪条更早”“哪条金额最大”，它只做等值比对：
-
(1001, 99.9)和(1001, 199.9)→ 不重复，都返回 -
(1001, 99.9)出现两次 → 只返回一次 -
user_id为NULL的多行 → 视为相同，只留一个
如果你真要“每个用户取最新/最高/任意一条”，DISTINCT 做不到，得用 GROUP BY 配合 MAX()、ROW_NUMBER() 或子查询。
为什么加了索引，DISTINCT 还很慢？
MySQL 对 DISTINCT 的优化依赖是否能走**覆盖索引**。如果执行 EXPLAIN SELECT DISTINCT city FROM users，发现 extra 列写着 Using temporary，说明没走索引去重，而是退化成临时表扫描。
关键点：
- 仅给
city加单列索引还不够——必须是**覆盖索引**，即索引里已包含所有SELECT字段（这里只有city，所以单列索引够用） - 但如果写的是
SELECT DISTINCT city, province FROM users，那必须建联合索引(city, province)，且顺序不能颠倒 - 如果表用的是
utf8mb4且字段长度大（如VARCHAR(255)），索引可能因前缀限制失效，需检查key_len
没索引时，2000 万行全扫 + 内存/磁盘临时表排序，30 秒不奇怪；加对索引后，可降到毫秒级。
COUNT(DISTINCT xxx) 和 GROUP BY COUNT(*) 哪个快？
单纯统计唯一值数量，COUNT(DISTINCT city) 通常比 SELECT city FROM t GROUP BY city; COUNT(*) 更轻量——前者是聚合层单次去重，后者要先分组再计数，额外生成中间结果集。
但注意两个陷阱：
-
COUNT(DISTINCT)在 MySQL 5.7 之前不支持并行，大数据量下仍是单线程处理 - 如果
city列 NULL 值极多，而你实际想排除 NULL 统计，得写COUNT(DISTINCT CASE WHEN city IS NOT NULL THEN city END)，否则 NULL 会被算作一个值 - 某些旧版本 MySQL 对
COUNT(DISTINCT)的执行计划不稳定，建议在生产环境用EXPLAIN FORMAT=TRADITIONAL确认是否走了索引
DISTINCT 和 GROUP BY 在语义与执行上根本不是一回事
别因为结果看起来一样就混用。例如 SELECT DISTINCT a, b FROM t 和 SELECT a, b FROM t GROUP BY a, b 虽然输出一致，但：
-
DISTINCT是查询修饰符，无分组语义，不能接HAVING或聚合函数（除非整个表达式包在COUNT()里） -
GROUP BY是分组操作，天然支持AVG(price)、HAVING COUNT(*) > 1等，且 MySQL 8.0+ 支持GROUP BY推导隐式排序，而DISTINCT不保证返回顺序（除非显式加ORDER BY） - 优化器对二者的路径选择可能不同：有些场景下
GROUP BY能利用松散索引扫描（Loose Index Scan），DISTINCT不能
真正需要去重又带业务逻辑（比如“每个城市取最贵商品”）时，硬套 DISTINCT 会绕远路，直接上 GROUP BY 或窗口函数更干净。
最常被忽略的一点：DISTINCT 不解决“我要哪一条”的问题——它只回答“有哪些不同的组合”。一旦需求里出现“最新”“最高”“第一条”，就该立刻切换思路，别在 DISTINCT 上死磕。
