COUNT(DISTINCT) + GROUP BY变慢主因是数据库为每个分组独立执行去重操作，如10万channel需做10万次哈希/排序；EXPLAIN出现Using temporary; Using filesort表明磁盘建临时表，性能断崖下跌；应改用先聚合再JOIN，将去重下沉至子查询，外层仅轻量关联，并配合分区裁剪与覆盖索引优化。
为什么COUNT(DISTINCT)一加GROUP BY就变慢？
不是语法错，是执行模型导致的——数据库对每个分组都独立跑一遍去重逻辑。比如按 channel 分 10 万组，就得做 10 万次哈希或排序，EXPLAIN 里一旦出现 Using temporary; Using filesort，基本等于在磁盘上建临时表，响应从毫秒跳到秒级甚至分钟级。
- 先确认是否真需要每组精确值：如果只是判断“是否超阈值”，用
LIMIT n+1配合子查询提前终止，比算出全部更省 - 避免在 JOIN 后才写
COUNT(DISTINCT)：优化器常因此放弃索引，改用先聚合再 JOIN 的方式下沉计算 - 检查
GROUP BY字段是否混入了高粒度列（如order_id、created_at）：分组过细会让每组内天然没几个重复值，结果看似“不准”，其实是分组逻辑错了
多列去重怎么写才不报错又跨库兼容？
不同数据库对 COUNT(DISTINCT col1, col2) 支持差异极大：MySQL 8.0.22+ 原生支持；PostgreSQL 要写成 COUNT(DISTINCT (col1, col2))（注意外层括号是行构造器）；SQL Server 和 Oracle 则必须用子查询。
- 最安全的跨库写法：
SELECT COUNT(*) FROM (SELECT DISTINCT col1, col2 FROM t) AS tmp，所有主流引擎都认，但大数据量下可能比原生语法慢 - 别用
CONCAT(col1, '|', col2)模拟：分隔符若出现在原始数据里（比如col1 = 'a|b'），就会把不同组合拼成相同字符串，造成误合并 - NULL 参与去重需显式转换：默认情况下
(1, NULL)和(NULL, 2)全被跳过；要用COUNT(DISTINCT COALESCE(col1, 'NULL_VAL'), COALESCE(col2, 'NULL_VAL'))，且替换值不能和真实数据冲突
索引到底有没有用？什么时候该建联合索引？
B-tree 索引对 COUNT(DISTINCT) 加速有限，但它能帮优化器减少扫描行数——尤其当查询带 WHERE 条件时。真正起效的是覆盖索引或联合索引设计。
- 单列去重 + WHERE 过滤：给
(filter_col, distinct_col)建联合索引，让条件过滤和去重字段都在索引里 - 分组后去重：比如
GROUP BY dept, COUNT(DISTINCT job, level)，优先建(dept, job, level)联合索引，避免回表和临时表 - 别迷信“有索引就快”：如果去重字段基数极低（如只有 3 个取值的
status），哈希去重开销远小于索引遍历，此时索引反而拖慢
大表上 COUNT(DISTINCT) 卡住，还能怎么救？
当数据量超百万、响应明显延迟，硬扛 COUNT(DISTINCT) 往往是错的选择。关键不是换写法，而是换目标：你要的到底是“精确数字”，还是“可用决策依据”？
- 接受误差换速度：PostgreSQL 用
APPROX_COUNT_DISTINCT()，BigQuery / Trino 用APPROX_COUNT_DISTINCT()，误差率通常 - 预聚合替代实时计算：把高频去重指标写进物化视图或定时任务汇总表，查询时直接读聚合结果
- 拆解逻辑绕开瓶颈：比如要同时统计
COUNT(DISTINCT a)和COUNT(DISTINCT b)，分别用两个子查询预聚合再JOIN，比写在一个语句里触发两次全量去重快得多
实际最难的从来不是写对语法，而是你没意识到字段里混着多少不可见字符、空字符串、NULL，还有执行计划里那个根本没走索引的 Using temporary; Using filesort。
