distinct最轻量但仅支持行级去重且不能聚合；group by可去重并支持聚合计算，索引友好但需严格遵循分组规则；二者性能取决于索引与执行计划。
用 DISTINCT 拿不重复值，最直接但有隐含限制
想快速去重查一列或多列的唯一组合，DISTINCT 是语法上最轻量的选择。但它不是“万能去重开关”——它只作用于 SELECT 子句的完整行投影，且无法配合聚合计算（比如同时要每个不重复值的出现次数）。
- 常见错误：写
SELECT DISTINCT name, COUNT(*) FROM users—— 会报错，因为没GROUP BY，COUNT(*)和DISTINCT不能混用 - 适用场景：纯查看有哪些唯一值，比如查所有省份
SELECT DISTINCT province FROM address - 注意 NULL：多个
NULL在DISTINCT下视为同一个值，会被合并成一行 - 性能影响：数据库仍需扫描全表并做内存/磁盘去重，大表时未必比
GROUP BY快，尤其当字段无索引时
GROUP BY 能替代 DISTINCT，还能多干点事
只要你在查不重复值的同时，还想顺手算点东西（比如出现次数、最大更新时间），GROUP BY 就是更通用的解法。它本质是按指定列分组，每组返回一行，天然去重。
- 等价写法：
SELECT DISTINCT city FROM shops≡SELECT city FROM shops GROUP BY city - 加分项：可以立刻加聚合函数，比如
SELECT city, COUNT(*) FROM shops GROUP BY city ORDER BY COUNT(*) DESC - 兼容性更好：某些旧版 MySQL（5.7 严格模式前）允许
SELECT city, name FROM shops GROUP BY city（name非确定），但现代标准和 PostgreSQL/SQL Server 会报错，务必确保SELECT中非分组字段都有聚合包裹 - 索引友好：如果
GROUP BY字段上有索引，数据库可能用索引扫描代替全表排序，速度明显提升
去重逻辑不同：DISTINCT 是行级去重，GROUP BY 是分组后取代表值
表面结果一样，但底层行为差异会影响你是否得到想要的数据。特别是多列组合或涉及 NULL 时，容易掉坑。
-
DISTINCT (a, b)去的是整行组合的重复，(1, NULL)和(1, NULL)算重复；但(1, NULL)和(1, '')不算重复（NULL ≠ 空字符串） -
GROUP BY a, b同样按组合分组，但如果你写SELECT a, MAX(b)，NULL 会被MAX()忽略（除非全为 NULL，才返回 NULL），结果可能和DISTINCT列表不一致 - 一个典型陷阱：用
GROUP BY id想“去重取最新一条”，但没加ORDER BY updated_at DESC或窗口函数，数据库随便返回该id组里某一行的其他字段，数据不可靠
大数据量时别只盯着语法，先看执行计划和索引
无论选 DISTINCT 还是 GROUP BY，真正卡住的往往不是写法，而是没走索引导致排序/哈希临时表撑爆内存。
- 检查执行计划：在语句前加
EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL），重点看有没有Using filesort或HashAggregate占用大量时间 - 索引建议：对高频去重字段建单列索引；多列组合去重（如
DISTINCT category, status），考虑联合索引(category, status)，顺序按查询中出现顺序来 - 避免 SELECT *：
DISTINCT *或GROUP BY配SELECT *会让数据库必须读取并比较所有字段，极大拖慢速度，只选必要字段
真正难的不是写 DISTINCT 还是 GROUP BY，而是搞清你要的“不重复”到底指什么——是单纯枚举值？还是按某个维度归总？以及数据库实际拿到的数据分布和索引覆盖情况，这两点漏掉，再短的 SQL 也跑不快。
