distinct用于获取唯一值列表，如部门名、城市名等，而group by用于分组统计；二者语义不同，不可混用，且需根据业务需求（是否需保留特定行）选择合适方法。
只想要唯一值列表，用 DISTINCT
比如查所有不重复的部门名、城市名、用户邮箱——没有统计需求，只要“有哪些”，DISTINCT 就是直觉且正确的选择。
常见错误是硬套 GROUP BY 去实现这个目标，结果要么报错（only_full_group_by 开启时），要么返回不可靠数据（关闭时随机取某一行）。
-
DISTINCT对整行去重：只有所有选中的字段值完全一致，才算重复 - 支持多列组合去重，例如
SELECT DISTINCT user_id, order_date FROM orders表示“同一用户同一天只留一条” -
NULL被视为一个独立值，多个NULL只保留一个 - 不能和聚合函数混用，像
SELECT DISTINCT COUNT(*)是语法错误
要按字段分组并算总数/平均值/最大值，必须用 GROUP BY
一旦业务问题里出现“每个……有多少”“平均……是多少”“最高……是哪个”，就不是去重问题，而是分组统计问题，GROUP BY 是唯一合规解法。
典型误区是写 SELECT dept, salary FROM emp GROUP BY dept 试图“去重部门并保留薪资”，这在 MySQL 8.0+ 默认配置下直接报错：Expression #2 of SELECT list is not in GROUP BY clause；即使关掉 only_full_group_by，salary 也会随机取分组内某条记录，结果不可信。
- 非分组字段必须显式聚合，例如
SELECT dept, MAX(salary) FROM emp GROUP BY dept - 多字段分组时，
GROUP BY dept, role意味着“按部门+角色组合分组”，不是分别去重 - 想同时去重又统计，得嵌套：先
DISTINCT子查询生成唯一组合，再外层GROUP BY
大数据量下性能差异明显，别凭感觉选
100 万行以上数据时，DISTINCT 和 GROUP BY 的执行计划可能完全不同，尤其涉及多列或无索引字段。
- 单列去重：通常
DISTINCT更快，数据库对纯去重有哈希优化 - 多列组合去重（如
user_id, product_id）：GROUP BY在某些引擎下反而更稳，因它天然走排序分组路径 - 没索引的字段上用
DISTINCT，容易触发临时表 + 文件排序，比GROUP BY更吃内存 - 实际执行前，务必用
EXPLAIN看是否走了索引，而不是只看语句“看起来简洁”
业务说“账单号去重，保留最新金额”，这不是 DISTINCT 或 GROUP BY 能直接解决的
这是典型的“单字段去重 + 保留指定行”的需求，DISTINCT 无法控制留哪条，GROUP BY 随机取值也不安全。真要这么做，得用窗口函数或子查询。
- MySQL 8.0+ 推荐：用
ROW_NUMBER() OVER (PARTITION BY bill_no ORDER BY create_time DESC)标记每组最新记录 - 旧版本可借
JOIN或WHERE NOT EXISTS找出“不存在更新时间更大的同账单号记录”的行 - 强行用
GROUP BY bill_no配MAX(amount)，得到的是最大金额，不是最新那笔的金额——两者语义不同
真正容易被忽略的，是业务语言里的“去重”常常隐含了“保留哪一条”的规则，而 SQL 的 DISTINCT 和 GROUP BY 都不承诺这个行为。
