count(distinct column)返回0主因是null值被忽略，整列null时结果为0；报错多因数据库版本不支持多列distinct或group by中非法嵌套聚合，如mysql 5.7不支持count(distinct col)在having中直接使用。
为什么 COUNT(DISTINCT column) 有时返回 0 或报错？
不是数据真为空，而是字段含 NULL —— COUNT(DISTINCT column) 会自动忽略 NULL 值，不报错但结果偏低。某些数据库（如老版本 MySQL）还不支持在 GROUP BY 子句中直接对 DISTINCT 列做聚合嵌套，会抛出 Invalid use of group function 错误。
实操建议：
- 先用
SELECT COUNT(*), COUNT(column), COUNT(DISTINCT column) FROM table对比三者，确认NULL占比 - 若需把
NULL当作一个独立类别统计，改用COUNT(DISTINCT COALESCE(column, 'NULL')) - 在 MySQL 5.7 及以下，避免写成
SELECT COUNT(DISTINCT col) FROM t GROUP BY x HAVING COUNT(DISTINCT col) > 1，应拆成子查询或临时表
PostgreSQL 和 SQLite 的 DISTINCT 行为差异
COUNT(DISTINCT ...) 在 PostgreSQL 中支持多列组合（如 COUNT(DISTINCT col1, col2)），SQLite 也支持，但 MySQL 直到 8.0.22 才支持多列 DISTINCT；之前版本只能靠 COUNT(DISTINCT CONCAT(col1, '|', col2)) 模拟，有长度截断和分隔符冲突风险。
实操建议：
- 跨数据库兼容时，优先用子查询去重：
SELECT COUNT(*) FROM (SELECT DISTINCT col1, col2 FROM t) AS _ - MySQL 5.7 下若
col1是 TEXT 类型，CONCAT可能被截断，改用MD5(CONCAT(col1, col2))更稳妥（但注意哈希碰撞概率极低，生产环境可接受） - PostgreSQL 中
DISTINCT多列会隐式按所有列排序去重，无索引时性能明显下降，建议在高频组合列上建复合索引
替代方案：什么时候不该用 COUNT(DISTINCT)？
当表行数超千万、目标列高基数（如用户 ID）、且无有效索引时，COUNT(DISTINCT) 会触发全表扫描 + 内存哈希表构建，可能 OOM 或耗时数十秒。这时不如换思路。
实操建议：
- 估算场景用
APPROX_COUNT_DISTINCT(col)（BigQuery / Spark SQL / PostgreSQL 13+ 支持），误差率通常 - 实时性要求不高时，改用物化视图或定时汇总表，例如每天凌晨跑
INSERT INTO daily_distinct_cnt SELECT DATE(created_at), COUNT(DISTINCT user_id) FROM logs WHERE created_at >= CURDATE() - INTERVAL 1 DAY GROUP BY DATE(created_at) - 应用层分页统计唯一值（如“前 1000 个不同城市”）别硬查全量，用
SELECT DISTINCT city FROM t LIMIT 1000+ 应用计数更轻量
GROUP BY 后再 COUNT(DISTINCT) 的典型误用
常见错误是写成 SELECT dept, COUNT(DISTINCT emp_id), AVG(salary) FROM emp GROUP BY dept，看起来没问题，但若某部门有 10 万员工，COUNT(DISTINCT emp_id) 仍要为每个分组单独构建哈希表——实际执行计划里会出现多次重复去重，性能比单次全量去重还差。
实操建议：
- 确认业务是否真需要每组的唯一计数；如果是为算“各部门员工覆盖率”，可能只需
COUNT(*)就够了 - 若必须分组去重且数据量大，考虑先用
ROW_NUMBER() OVER (PARTITION BY dept, emp_id ORDER BY id)标记首行，再外层GROUP BY dept统计标记为 1 的行数 - MySQL 中可利用
GROUP_CONCAT(DISTINCT emp_id)拼接后取长度粗略对比，仅用于调试，不可用于精确统计
真正卡住人的往往不是语法，而是 DISTINCT 在不同引擎里对内存、排序、索引的实际依赖方式——查之前先 EXPLAIN 看执行计划，比背函数手册管用得多。
