COUNT(DISTINCT) 性能瓶颈在于与分组、连接、过滤耦合在同一层，应下沉至子查询预聚合，配合分区裁剪和联合索引避免临时表与全表扫描。

因为 COUNT(DISTINCT) 在每个分组内都得独立做一次哈希或排序去重，数据量大、分组多时，CPU 和临时磁盘开销会指数级上涨——不是“慢一点”，而是可能从毫秒级跳到分钟级。

为什么 EXPLAIN 出现 Using temporary; Using filesort 就该警觉

这表示 MySQL 正在磁盘上建临时表来完成去重，已彻底脱离内存哈希路径。尤其当 GROUP BY 字段基数高（比如 10 万 channel）、DISTINCT 字段本身也高基数（如 user_id）时，每个分组都要跑一遍全量去重逻辑，IO 和 CPU 双爆。

• 别信“加个索引就能快”——COUNT(DISTINCT) 很难直接走索引跳过排序，除非满足松散索引扫描条件（如 GROUP BY a 且索引是 (a, b)，同时只查 MAX(b) 这类有序聚合）
• WHERE 条件没下推到子查询里？分区字段（如 dt）漏写？那整个大表都会被扫一遍
• MySQL 5.7+ 中，如果 SELECT 字段未被联合索引完全覆盖，优化器大概率放弃索引，强制回表 + 临时表

把 COUNT(DISTINCT) 沉到子查询里再 JOIN

核心思路：不让去重和分组耦合在一层，把高成本动作“下沉”，让外层只做轻量关联。

原始写法（危险）：

SELECT b.name, COUNT(DISTINCT a.user_id)
FROM table_a a
JOIN table_b b ON a.dashboard_id = b.id
GROUP BY b.name;

优化后（推荐）：

SELECT b.name, new_a.ct
FROM table_b b
JOIN (
  SELECT dashboard_id, COUNT(DISTINCT user_id) AS ct
  FROM table_a 
  WHERE dt = '2026-09'  -- 必须加！否则子查询仍扫全表
  GROUP BY dashboard_id
) new_a ON new_a.dashboard_id = b.id;

• 子查询结果集极小（比如几百个 dashboard_id），JOIN 成本几乎可忽略
• WHERE dt = ... 必须写在子查询内，才能触发分区裁剪
• 若 table_a 有联合索引 (dashboard_id, user_id, dt)，这个子查询甚至能避免排序

多个 COUNT(DISTINCT) 同时出现必须拆开算

写成 COUNT(DISTINCT user_id), COUNT(DISTINCT order_no) 看似简洁，但 Spark / Hive / MySQL 都会为每个启动独立去重通道，shuffle 数据翻倍，内存压力陡增。

正确做法是分别预聚合再 JOIN：

SELECT t1.channel, t1.user_cnt, t2.order_cnt
FROM (
  SELECT channel_code AS channel, COUNT(DISTINCT user_id) AS user_cnt
  FROM user_order 
  WHERE del_flag = '0' AND create_date BETWEEN '2026-01-01' AND '2026-09-30'
  GROUP BY channel_code
) t1
JOIN (
  SELECT channel_code AS channel, COUNT(DISTINCT order_no) AS order_cnt
  FROM user_order 
  WHERE del_flag = '0' AND create_date BETWEEN '2026-01-01' AND '2026-09-30'
  GROUP BY channel_code
) t2 ON t1.channel = t2.channel;

• 两个子查询可并行执行，且各自结果集小、可控
• WHERE 条件重复写不可怕，怕的是漏写导致全表扫描
• 字段越多，越要警惕——三个 COUNT(DISTINCT) 就意味着三倍 shuffle 量

最易被忽略的一点：COUNT(DISTINCT) 的性能瓶颈从来不在“去重”本身，而在于它强迫数据库把去重动作和分组、连接、过滤这些操作绑死在同一执行层级。只要把它从主查询里拎出来，哪怕多写几行 SQL，性能拐点往往就出现在那一层子查询的边界上。