distinct是作用于select列表的关键字，不可用于where或order by；其去重基于整行，多列时需同写；null被视为相同值；性能差时应建索引或改用group by。
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。
例如表中 email 列有 3 行是 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 可能无法利用索引完成排序+去重，得结合业务看能否预计算或加缓存。
