SQL标准禁止DISTINCT与GROUP BY共用，因执行逻辑冲突导致报错或性能断崖式下降；优化需用子查询预过滤分组键，避免全表扫描与多次临时表构建。
为什么直接写 DISTINCT + GROUP BY 会报错或变慢
SQL标准明确禁止在同一个 SELECT 中同时出现 DISTINCT 和 GROUP BY，主流数据库（MySQL/PostgreSQL/SQL Server）都会报类似 "DISTINCT and GROUP BY are mutually exclusive" 的错误。但有些用户绕过语法检查后强行执行（比如 MySQL 低版本或关闭严格模式），结果是性能断崖式下跌——26万行数据查18秒很常见。
根本原因在于执行逻辑冲突：GROUP BY 先分组再聚合，DISTINCT 是对最终结果集做行级去重。两者叠加会让优化器陷入“先分多少组？按哪一列去重？”的歧义，被迫退化为全表扫描 + 多次临时表构建 + 随机排序，Handler_read_rnd_next 指标飙升就是典型信号。
用子查询预过滤替代嵌套 GROUP BY + DISTINCT
核心思路是：把“取哪几组”的逻辑提前抽出来，只让外层做真正需要的聚合计算，避免在海量原始数据上反复分组。
- 原写法（慢）：
SELECT DISTINCT channel_code, DATE_FORMAT(create_date, '%Y'), COUNT(DISTINCT order_no) FROM user_order WHERE del_flag='0' GROUP BY channel_code, DATE_FORMAT(create_date, '%Y') - 优化后（快）：
SELECT b.channel_code, DATE_FORMAT(b.create_date, '%Y'), COUNT(DISTINCT b.order_no) FROM user_order b JOIN (SELECT DISTINCT channel_code, DATE_FORMAT(create_date, '%Y') AS y FROM user_order WHERE del_flag='0' AND create_date BETWEEN '2017-01-01' AND '2018-12-31') t ON b.channel_code = t.channel_code AND DATE_FORMAT(b.create_date, '%Y') = t.y WHERE b.del_flag='0' GROUP BY b.channel_code, DATE_FORMAT(b.create_date, '%Y')
关键点：
- 子查询只取分组键组合，不碰原始明细，体积小、速度快
- 外层
JOIN后的数据集已大幅缩小，GROUP BY不再扫全表 - 若需分页（如
LIMIT 80,20），必须放在子查询里，否则外层仍要处理全部分组
COUNT(DISTINCT) 在 GROUP BY 中的性能陷阱
当 GROUP BY 分组数多、每组内 COUNT(DISTINCT x) 字段值又高度离散时，内存哈希表会急剧膨胀，甚至触发磁盘临时表。这不是写法错，而是算法瓶颈。
- 避免在
GROUP BY中直接算多个COUNT(DISTINCT)（如同时统计不同用户的订单数和商品数） - 优先考虑物化中间结果：用
CREATE TEMPORARY TABLE或 CTE 先聚合出基础分组，再二次加工 - 如果业务允许近似结果，可用
APPROX_COUNT_DISTINCT()（BigQuery/Spark）或HLL_SKETCH（PostgreSQL + hll 扩展）替代
索引怎么建才真正帮上 GROUP BY + DISTINCT 的忙
光有索引不够，顺序和覆盖范围必须匹配实际执行路径。例如查询：SELECT channel_code, DATE_FORMAT(create_date, '%Y'), COUNT(DISTINCT order_no) FROM user_order WHERE del_flag='0' GROUP BY channel_code, DATE_FORMAT(create_date, '%Y')
- 无效索引：
(create_date, channel_code)——del_flag没覆盖，且函数表达式无法走索引 - 有效索引：
(del_flag, channel_code, create_date)——del_flag等值过滤打头，channel_code支持分组排序，create_date虽被函数包裹，但至少能利用范围剪枝 - 更优方案：把
DATE_FORMAT(create_date, '%Y')提前物化为新字段（如order_year），并为其建索引，彻底规避函数调用
真正卡住性能的往往不是语法对不对，而是分组键有没有被索引“自然承载”——物理顺序是否能让数据库跳过排序阶段，直接流式分组。
