count distinct 慢的核心原因是缺乏适配去重计算的索引结构，需全量扫描并排序或哈希去重；普通b-tree索引无法避免遍历所有值，高基数下性能更差；有效方案包括覆盖索引+预聚合、物化视图、位图/函数索引（低基数场景）及hyperloglog近似算法。
COUNT DISTINCT 慢，核心问题往往不在 SQL 写法本身，而在缺少支撑去重计算的合适索引结构。数据库执行 COUNT(DISTINCT col) 时，通常需先提取所有非 NULL 值、排序去重（或哈希去重），再计数——这个过程无法跳过数据扫描，且中间结果不可索引加速。单纯在列上建普通 B-Tree 索引，对 COUNT DISTINCT 效果有限，因为索引只优化查找/范围扫描，不直接提供“已去重的唯一值集合”。
为什么普通单列索引对 COUNT DISTINCT 加速有限
普通索引（如 CREATE INDEX idx_user_id ON orders(user_id);）能快速定位某 user_id 是否存在，也能支持 GROUP BY user_id 的聚合，但面对 COUNT(DISTINCT user_id)，数据库仍需遍历索引中所有 user_id 条目（或回表取值），再做去重统计。尤其当该列高基数、数据量大时，内存中哈希表膨胀或外部排序开销显著。
真正有效的索引设计方向
- 覆盖索引 + 预聚合（推荐）：若业务允许一定延迟（如 T+1 报表），可在 ETL 或定时任务中维护一张轻量维表，例如 user_distinct_summary(day, cnt_users)，每日更新。查询直接 SELECT cnt_users FROM ... WHERE day = '2024-06-01'，毫秒级响应。
- 物化视图（PostgreSQL / Oracle / MySQL 8.0+）：创建自动刷新的物化视图存储去重结果。例如 PostgreSQL 中：CREATE MATERIALIZED VIEW mv_user_count AS SELECT COUNT(DISTINCT user_id) AS cnt FROM orders; 后续查询 SELECT * FROM mv_user_count 可完全避免实时计算。
- 函数索引 + 位图索引（特定场景）：对低基数列（如 status、region），可考虑位图索引（Oracle / PostgreSQL）；或用函数索引固化分组逻辑，如 CREATE INDEX idx_status_date ON orders((status, DATE(created_at)));，配合 WHERE status = 'paid' AND created_at >= '2024-01-01' 的 COUNT DISTINCT，可能借助索引范围裁剪减少扫描量。
- 近似去重（大数据量首选）：用 HyperLogLog 类算法（如 PostgreSQL 的 hll 扩展、ClickHouse 的 uniqCombined、Spark 的 approx_count_distinct）。误差率通常
必须避开的误区
- 给 COUNT(DISTINCT col) 列单独加普通索引，期望“自动变快”——大概率无效，需验证执行计划（EXPLAIN ANALYZE）是否真的用到索引且减少行扫描数。
- 在高并发 OLTP 表上频繁跑 COUNT DISTINCT，未做读写分离或查询降级——应将报表类查询路由至只读副本或数仓层。
- 忽略 NULL 值影响：COUNT(DISTINCT col) 自动忽略 NULL，但若业务语义需包含“未知”状态，应提前用 COALESCE 转换，否则索引设计与统计口径错位。
快速验证与调优步骤
- 先运行 EXPLAIN (ANALYZE, BUFFERS) SELECT COUNT(DISTINCT user_id) FROM orders WHERE created_at > '2024-05-01';，观察是否全表扫描、是否触发临时文件（Disk:）、实际处理行数。
- 尝试强制走索引：SELECT COUNT(DISTINCT user_id) FROM orders WHERE created_at > '2024-05-01' AND user_id IS NOT NULL;（确保条件能命中索引）。
- 对比加覆盖索引后的效果：CREATE INDEX idx_orders_cover ON orders(created_at, user_id) WHERE created_at IS NOT NULL;（注意部分索引过滤条件需匹配查询 WHERE）。
- 评估是否可改用近似函数，如 PostgreSQL：SELECT #hll_add_agg(hll_hash_integer(user_id)) FROM orders WHERE ...;
