count(distinct column) 返回0而非null，是因为它完全忽略null值——既不参与去重也不计入计数；整列全为null时结果为0，若需将null视为有效值，须用coalesce转换。

为什么 COUNT(DISTINCT column) 返回 NULL 或 0？

常见原因是字段本身包含大量 NULL 值——COUNT(DISTINCT) 会忽略所有 NULL，如果整列都是 NULL，结果就是 0；如果误以为 NULL 会被当作一个独立值去重，就会困惑为什么没被计入。

• COUNT(DISTINCT) 永远不统计 NULL，哪怕只有一行非空值，其余全为 NULL，结果也是 1
• 想把 NULL 当作一种“有效取值”参与去重？得先用 COALESCE(column, 'NULL_PLACEHOLDER') 转换
• MySQL 5.7+ 和 PostgreSQL 行为一致；但旧版 SQLite（COUNT(DISTINCT) 多列，单列没问题

COUNT(DISTINCT) 能不能对多列组合去重？

可以，但语法和效果容易误解：写成 COUNT(DISTINCT col1, col2) 是合法的（MySQL、PostgreSQL、SQL Server 支持），它统计的是 (col1, col2) 元组的唯一组合数，不是分别对两列去重再相加。

Question AI

一款面向学习和知识查询场景的AI助手，提供问题解答、内容和智能搜索等功能。

下载

• 错误理解：COUNT(DISTINCT a, b) ≠ COUNT(DISTINCT a) + COUNT(DISTINCT b)
• 正确等价写法（兼容性更好）：COUNT(*) 配合 GROUP BY a, b 子查询，但性能通常更差
• 注意：Oracle 不支持多列 DISTINCT 直接写在 COUNT() 里，必须用子查询或 GROUP BY

性能很慢？别直接套用 COUNT(DISTINCT)

在大表上执行 COUNT(DISTINCT) 往往触发全表扫描 + 内存哈希去重，尤其当去重字段无索引或基数极高时，响应可能从毫秒级跳到分钟级。

• 优先检查该字段是否有索引——B-tree 索引对 COUNT(DISTINCT) 加速有限，但位图索引（如 PostgreSQL）或物化视图可缓解
• 数据量超百万行？考虑用近似函数替代，比如 PostgreSQL 的 APPROX_COUNT_DISTINCT()，误差率
• 如果只是判断“是否超过阈值”，可用 LIMIT n+1 配合子查询提前终止，比算出精确值快得多

GROUP BY 后再 COUNT(DISTINCT) 容易漏掉空组

当配合 GROUP BY 使用时，COUNT(DISTINCT) 对每组单独计算，但如果某组没有任何非空值（例如全为 NULL），该组仍会出现在结果中，且对应值为 0 —— 这不是 bug，是符合 SQL 标准的行为。

• 想排除“空组”？加 HAVING COUNT(DISTINCT col) > 0 过滤
• 需要显示“0 条记录”的组？确保 GROUP BY 字段本身不为 NULL，否则那行根本不会进分组（除非用 GROUPING SETS）
• MySQL 8.0+ 支持 GROUP BY ... WITH ROLLUP，但 COUNT(DISTINCT) 在 rollup 行表现不稳定，建议避免混用

实际去重计数最麻烦的从来不是语法，而是你没意识到字段里藏了多少 NULL、空字符串、不可见字符，还有执行计划里那个没走索引的 Using temporary; Using filesort。