distinct 只能作用于 SELECT 列表，不能用于 WHERE 或 ORDER BY
很多人写
DISTINCT时误以为它是个函数，比如
SELECT DISTINCT(name) FROM user，这是错的——
DISTINCT是关键字，修饰整个
SELECT行。括号不改变语义，反而容易误导。
正确写法是：
SELECT DISTINCT name FROM user。如果要多列去重，必须写成
SELECT DISTINCT name, age FROM user，此时“去重”是按整行判断：只要
name和
age组合相同，就视为重复。 不能写
SELECT name, DISTINCT age（语法错误） 不能在
WHERE中用
DISTINCT col过滤（无意义，也不合法）
ORDER BY可以引用
SELECT中的列别名，但不能对未出现在
SELECT中的列排序（除非该列也在
DISTINCT列表里）
distinct 和 group by 去重效果一样，但语义和限制不同
单字段纯去重时，
SELECT DISTINCT col FROM t和
SELECT col FROM t GROUP BY col返回结果一致，但底层行为不同：
DISTINCT是查询结果集层面去重，不支持聚合计算（如
COUNT、
AVG），也不能加
HAVING
GROUP BY是分组操作，天然支持聚合；若你后续想统计每组数量，直接加
COUNT(*)就行，而
DISTINCT必须套子查询或改写 MySQL 8.0+ 对
DISTINCT会自动尝试用松散索引扫描优化，但前提是字段有合适索引；
GROUP BY的优化路径更可控，尤其配合
SQL_BIG_RESULT提示时
所以，只取唯一值 → 用
DISTINCT；需要附带统计/条件筛选 → 直接上
GROUP BY。
distinct 在包含 NULL 的列上会把所有 NULL 当作同一值
MySQL 认为
NULL = NULL为未知（
UNKNOWN），但在
DISTINCT和
GROUP BY中，所有
NULL被视为相等，因此只会保留一个
NULL。
例如表中
NULL，执行
SELECT DISTINCT email FROM user只返回一行
NULL。 这不是 bug，是 SQL 标准行为 如果你需要区分“多个 NULL”，说明业务上它们不是真正意义上的“相同”，应考虑用默认值（如
'<unknown>'</unknown>）替代
NULL，或在应用层处理 注意：联合去重时，只要任意一列是
NULL，整行比较仍遵循该规则，比如
(1, NULL)和
(1, NULL)被去重，但
(1, NULL)和
(1, 'a@b.c')不会
性能差？先看执行计划，再考虑加索引或改写
DISTINCT没有索引支撑时，MySQL 往往走全表扫描 + 内存临时表（
Using temporary），数据量大时明显变慢。 用
EXPLAIN SELECT DISTINCT col FROM t看是否出现
Using temporary；如果有，且
col频繁用于去重，优先建索引：
CREATE INDEX idx_col ON t(col)复合去重（如
DISTINCT a, b）建议建联合索引：
CREATE INDEX idx_a_b ON t(a, b)，顺序按查询中列顺序来 如果只是想“随便取一条”而非严格去重，
GROUP BY配合
MIN(id)或窗口函数更灵活，避免大临时表
真正难优化的是带
ORDER BY和
LIMIT的去重查询，比如 “取前 10 个不重复的 tag”。这时 MySQL 可能无法利用索引完成排序+去重，得结合业务看能否预计算或加缓存。
