COUNT(DISTINCT col)必须建临时去重集合，因其需在内存或磁盘中维护哈希表或排序结构，逐行判断并存储唯一值，无法跳过该过程；无索引、低选择性、多列组合或高基数场景下易触发全表扫描与落盘，导致性能断崖式下降。

为什么 COUNT(DISTINCT) 必须建临时去重集合

COUNT(DISTINCT col) 不是简单遍历加个计数器就能完成的。数据库必须在内存或磁盘中维护一个去重结构（如哈希表或排序后的唯一值列表），每遇到一个新值就判断是否已存在，再决定是否插入。这个过程无法跳过、无法并行化到单次扫描外——哪怕你只查一列，它也得把所有匹配行的 col 值全拉出来跑一遍去重逻辑。

常见错误现象：EXPLAIN 中看到 Using temporary; Using filesort（MySQL）或 HashAggregate（PostgreSQL）就说明正在干这事；如果数据量大且无索引，大概率触发全表扫描 + 内存溢出写磁盘，速度断崖式下跌。

COUNT(DISTINCT) 的性能瓶颈在哪几类场景最明显

不是所有 COUNT(DISTINCT) 都慢，但以下情况会显著放大开销：

• 去重字段选择性极低：比如 status 只有 'pending'、'done'、'failed' 三个值，却对上亿行做 COUNT(DISTINCT status)——数据库仍要逐行读、逐行哈希、逐行判重，浪费大量 I/O 和 CPU
• 字段无索引且查询条件无法过滤掉大部分数据：例如 WHERE created_at > '2025-01-01' 本可快速定位，但 created_at 没索引，引擎只能扫全表，再对每一行提取 user_id 去重
• 多列去重：COUNT(DISTINCT user_id, product_id) 要对组合值哈希，内存占用和碰撞概率都比单列高得多；SQLite 和 SQL Server 2014 及以前还不支持，直接报错 Incorrect syntax near ','
• 嵌套子查询里反复用：SELECT a, COUNT(DISTINCT b), COUNT(DISTINCT c) FROM t GROUP BY a 在传统执行器中会触发两次独立去重，不是一次扫描搞定

什么时候该放弃 COUNT(DISTINCT) 改用近似统计

当你要同时算多个去重指标，或单次去重基数超过千万级且允许小误差时，硬扛 COUNT(DISTINCT) 就是自找麻烦。

可用方案包括：

• BigQuery / Spark SQL：APPROX_COUNT_DISTINCT(col)，误差通常
• Trino / Presto：approx_distinct(col)
• PostgreSQL：没有内置近似函数，但可用 #(SELECT array_agg(DISTINCT x) FROM t)？别试——这是错的，array_agg 不去重，且会爆内存
• 真要精确又快：提前物化去重结果到汇总表，或用 MATERIALIZED VIEW（PostgreSQL 9.4+）定期刷新

容易被忽略的关键细节

COUNT(DISTINCT) 对 NULL 自动忽略，这点和 SUM、AVG 一致，但和 COUNT(*) 不同——后者会把 NULL 行也算进去。如果你的业务逻辑依赖 NULL 计入总数，就不能用 DISTINCT，得换思路，比如用 COUNT(*) - COUNT(col) 算 NULL 个数。

另外，COUNT(DISTINCT *) 是语法错误，DISTINCT 后面必须跟具体列或表达式，不能偷懒。