COUNT(DISTINCT 多字段)可直接使用，统计的是字段组合的唯一行数（如(user_id, action_type)二元组），而非各字段分别去重；NULL被视为一个值，多个NULL只计1次，且旧版SQL Server等不支持时需改用子查询。
COUNT(DISTINCT) 能不能直接用在多字段上
可以，但语义和单字段不同：它统计的是“字段组合的唯一行数”，不是各字段分别去重后相乘或相加。比如 COUNT(DISTINCT user_id, action_type) 统计的是有多少个不同的 (user_id, action_type) 二元组，而不是用户数 × 行为类型数。
常见误用是以为它等价于嵌套子查询或先 GROUP BY 再 COUNT，其实不是——它天然按整行组合去重，不依赖分组上下文。
- MySQL 5.7+、PostgreSQL、SQL Server 2017+、Oracle、SQLite 都支持多字段
DISTINCT - 旧版 SQL Server（2016 及更早）不支持多字段
DISTINCT，会报错Incorrect syntax near ',' - 如果目标数据库不支持，得改写成
SELECT COUNT(*) FROM (SELECT DISTINCT user_id, action_type FROM events) t
为什么 COUNT(DISTINCT) 比子查询慢很多
本质是执行计划差异：COUNT(DISTINCT col) 通常触发哈希聚合（Hash Aggregate）或排序去重（Sort + Unique），而大表上哈希内存不足时会 spill 到磁盘，性能断崖式下降；子查询写法（SELECT COUNT(*) FROM (SELECT DISTINCT col FROM t) t2）可能让优化器选择索引扫描 + 去重物化，反而更快。
- 有索引的字段（如主键、唯一索引列）上用
COUNT(DISTINCT)一般没问题 - 对无索引的文本字段（如
email或description）做COUNT(DISTINCT)，容易触发大量内存/磁盘 I/O - PostgreSQL 中可加
SET work_mem = '64MB'临时提升哈希内存，但别在生产会话里乱设
NULL 值在 COUNT(DISTINCT) 中怎么算
NULL 被视为一个独立值，但所有 NULL 彼此相等，所以多个 NULL 只算作 1 次去重结果。例如表中 country 字段有 ['CN', 'US', NULL, NULL, 'JP']，COUNT(DISTINCT country) 返回 4（CN、US、JP、NULL 各一）。
- 如果业务上想排除
NULL，必须显式过滤：COUNT(DISTINCT CASE WHEN country IS NOT NULL THEN country END) - 不要用
COUNT(DISTINCT COALESCE(country, ''))，因为''和NULL是不同值，会把空字符串也计入 - 某些老版本 SQLite（NULL 的处理略有偏差，建议升级
替代方案：当 COUNT(DISTINCT) 不可用或太慢时怎么办
最直接的替代是子查询物化去重，但要注意写法细节。比如想统计每个部门的活跃用户数，又不想用 COUNT(DISTINCT user_id)：
SELECT dept, COUNT(*) AS active_users FROM ( SELECT DISTINCT dept, user_id FROM user_events WHERE event_time >= '2024-01-01' ) t GROUP BY dept;
这个写法比在外部加 COUNT(DISTINCT user_id) GROUP BY dept 更可控，尤其在 MySQL 5.6 或早期 TiDB 上。
- 避免在子查询里漏掉
WHERE条件——外层加条件会导致去重前数据膨胀 - 如果只是要总数（非分组），且数据量极大，考虑用 HyperLogLog 近似算法（如 PostgreSQL 的
HLL_COUNT_INIT/HLL_COUNT_MERGE） - ClickHouse 直接提供
uniq()函数，性能远超标准COUNT(DISTINCT)，但语法不兼容
rows 和 Extra 字段有没有 Using temporary 或 Using filesort，再决定要不要换写法。去重逻辑越靠近数据源头（WHERE、JOIN 条件），后面 COUNT 的压力越小。 
