count(distinct)更慢的根本原因是其单次扫描中需实时维护哈希表或排序结构跟踪所有唯一值，内存与cpu开销大；而子查询+count(*)可先利用索引过滤、轻量去重，再对小结果集计数，更易走覆盖索引、内存占用低、并行友好。
为什么COUNT(DISTINCT)比子查询+COUNT(*)还慢
根本原因在于执行路径不同：COUNT(DISTINCT col) 要求数据库在单次扫描中完成去重+计数，必须维护一个哈希表或排序结构来跟踪所有唯一值；而 SELECT COUNT(*) FROM (SELECT DISTINCT col FROM t WHERE ...) 先做一次轻量级去重（可利用索引、可提前过滤），再对已去重的小结果集计数——后者更容易走覆盖索引、更少内存占用、更易并行。
子查询写法必须满足的三个前提条件
不是所有 SELECT COUNT(*) FROM (SELECT DISTINCT ...) 都快，它只在以下情况真正生效：
- WHERE 条件足够强，能大幅减少输入行数（比如
dt >= '2026-04-15'，而不是status IN ('a','b','c')这种低选择率条件） - 去重字段
col有单列索引或作为联合索引最左前缀（否则子查询仍要全表扫） - 子查询结果集行数远小于原始表（理想是 COUNT(*) 反而多一次遍历
MySQL中容易被忽略的索引陷阱
即使你给 user_id 加了索引，COUNT(DISTINCT user_id) 仍可能不走索引——因为 MySQL 优化器发现去重逻辑无法跳过 NULL 值判断或需要回表取其他字段时，会主动放弃索引扫描。但子查询方式可以绕过这个限制：
✅ 正确建索引示例：CREATE INDEX idx_dt_uid ON log (dt, user_id)，配合查询 SELECT COUNT(*) FROM (SELECT DISTINCT user_id FROM log WHERE dt BETWEEN '2026-04-18' AND '2026-04-22') t
⚠️ 错误用法：如果子查询里写了 SELECT DISTINCT user_id, name FROM ...，哪怕只为了去重 user_id，也会因 name 不在索引中触发回表，性能反而更差
Spark SQL里用子查询替代COUNT(DISTINCT)要防Expand膨胀
Spark 中多个 COUNT(DISTINCT) 会触发 Expand 节点，把 1 行变成 N 行（N=去重字段数），导致 shuffle 数据量暴增。而子查询方式天然规避该问题：
❌ 慢写法：SELECT dt, COUNT(DISTINCT uid), COUNT(DISTINCT aid) FROM events GROUP BY dt
✅ 快写法（拆开）：SELECT a.dt, a.uv, b.av FROM (SELECT dt, COUNT(*) AS uv FROM (SELECT DISTINCT dt, uid FROM events WHERE dt >= '2026-04-18') GROUP BY dt) a JOIN (SELECT dt, COUNT(*) AS av FROM (SELECT DISTINCT dt, aid FROM events WHERE dt >= '2026-04-18') GROUP BY dt) b ON a.dt = b.dt
注意：这种拆分在 Spark 中实际是分两轮 job 执行，虽然总耗时未必减半，但避免了单 job 因 Expand 导致的严重数据倾斜和 OOM
真正卡住性能的，往往不是语法本身，而是去重发生在哪一层——是在扫描 10 亿行时边读边去重，还是先用索引筛出 10 万行再丢进哈希表。选错层级，优化就从根上失效。
