多列COUNT(DISTINCT)比单列慢，因需对组合值构建唯一哈希集或排序去重，字段越宽、取值越分散，内存与比较开销越大；无索引时易触发临时表和文件排序，磁盘IO成瓶颈。
多列COUNT(DISTINCT)为什么比单列慢得多
因为数据库必须对所有指定列的组合值构建唯一哈希集或排序去重，而组合字段越宽、取值越分散，内存占用和比较开销就越大。比如 COUNT(DISTINCT user_id, product_id) 实际要维护的是 (user_id, product_id) 二元组的集合，其基数远高于单独的 user_id 或 product_id；若两列都无索引，MySQL 会触发 Using temporary; Using filesort，PostgreSQL 可能走全表 Seq Scan + HashAggregate，磁盘临时表 IO 成为瓶颈。
哪些场景下多列COUNT(DISTINCT)根本没必要
很多写法是语义错误，不是性能问题——而是压根不该这么写：
- 想统计“每个用户买了几种商品”，却写了
SELECT user_id, COUNT(DISTINCT user_id, product_id)：这算的是 (user_id, product_id) 对总数，不是 per-user 的去重商品数；正确写法是COUNT(DISTINCT product_id) GROUP BY user_id - 用
COUNT(DISTINCT *)：语法非法，DISTINCT后必须跟明确列名或表达式 - 在 WHERE 条件已能保证唯一性时硬加多列 DISTINCT，比如
SELECT DISTINCT id, created_at FROM logs WHERE id = 123：直接SELECT id, created_at FROM logs WHERE id = 123 LIMIT 1更快且语义清晰
替代方案：不改语义的前提下降低开销
当业务真需要多列去重计数（如“不同用户-设备组合总数”），又无法接受全量去重代价，可考虑：
- 建联合索引加速去重过程：
CREATE INDEX idx_user_device ON events(user_id, device_id)，让 MySQL/PostgreSQL 能用索引覆盖扫描，避免回表 - 用近似函数换精度保速度：BigQuery 用
APPROX_COUNT_DISTINCT(user_id, device_id)，Trino/Presto 用同名函数，误差通常 - 分步聚合：先
GROUP BY user_id, device_id去重生成中间结果，再COUNT(*)统计行数，虽多一层 CTE，但可利用索引 + 避免大哈希表，尤其适合高并发小查询
SQLite 和旧版 SQL Server 的兼容性陷阱
它们不支持多列 DISTINCT 语法，写 COUNT(DISTINCT a, b) 会直接报错 Incorrect syntax near ','。此时必须改写为子查询：SELECT COUNT(*) FROM (SELECT DISTINCT a, b FROM t)，但要注意这会失去窗口函数能力，也无法用于 HAVING 子句中。
真正难优化的不是语法本身，而是你没法只靠加索引就绕过“组合去重”这个计算本质——只要业务要求的是精确的多维唯一基数，就得付出对应代价。别迷信“加个索引就快”，先确认是不是真需要它。
