count(distinct column) 慢主因是缺乏高效索引支持或优化器无法跳过全表扫描；推荐用覆盖索引+子查询、物化汇总表、函数/表达式索引或近似算法优化。
SQL 中 COUNT(DISTINCT column) 慢，通常不是因为函数本身“有问题”，而是缺乏合适的索引支持，或数据分布/查询结构导致优化器无法高效执行。直接加普通索引对 DISTINCT 聚合帮助有限——关键在于**让数据库能跳过全表扫描，快速定位去重后的值范围**。
为什么普通单列索引对 COUNT(DISTINCT) 效果差？
普通 B-Tree 索引能加速等值查询、排序和范围扫描，但 COUNT(DISTINCT) 需要统计所有不同值的个数。即使有索引，MySQL（尤其是 8.0 之前）、PostgreSQL 等仍常选择全索引扫描 + 内存哈希去重，而非利用索引结构天然去重。如果该列 NULL 多、重复率高、或结果集本身不大，优化器甚至可能放弃索引走全表扫描。
真正有效的索引策略
-
覆盖索引 + 子查询去重（推荐）：用
SELECT COUNT(*) FROM (SELECT DISTINCT column FROM table WHERE ... ORDER BY NULL) t，并确保外层能走覆盖索引。例如在(status, created_at)上建联合索引，当查询COUNT(DISTINCT status)且带WHERE created_at > '2024-01-01'时，索引可同时满足过滤与去重需求。 -
物化中间结果（大数据量场景）：对高频查询的
DISTINCT统计，可定期写入汇总表（如每天凌晨跑INSERT INTO daily_distinct_counts SELECT DATE(created_at), COUNT(DISTINCT user_id) FROM logs GROUP BY DATE(created_at)），查时直取，毫秒响应。 -
升级到支持函数索引的版本（如 MySQL 8.0.13+、PostgreSQL 12+）：可建函数索引
CREATE INDEX idx_distinct_user ON orders ((DISTINCT user_id))—— 注意：MySQL 实际不支持这种语法，但 PostgreSQL 支持表达式索引，如CREATE INDEX idx_user_distinct ON orders (user_id)本身虽非“DISTINCT索引”，但配合GROUP BY或位图扫描可显著提速；MySQL 更现实的做法是用生成列+索引：ALTER TABLE orders ADD COLUMN user_id_n AS (CASE WHEN user_id IS NOT NULL THEN user_id END) STORED;，再对user_id_n建索引并WHERE user_id_n IS NOT NULL过滤。
别忽略的细节优化
-
避免在 DISTINCT 列上用函数或表达式：如
COUNT(DISTINCT UPPER(name))会强制计算，无法走索引。提前在应用层或用生成列标准化。 -
检查统计信息是否准确：过期的表分析（
ANALYZE TABLE/VACUUM ANALYZE）会让优化器误判，选错执行计划。 -
考虑近似去重（允许少量误差）：如 HyperLogLog 算法，MySQL 8.0+ 的
APPROX_COUNT_DISTINCT()、Redshift 的APPROXIMATE COUNT(DISTINCT)、或 ClickHouse 的uniq()，性能提升可达 10 倍以上，适合监控类场景。
索引重构不是简单换个字段顺序，而是结合查询模式、数据特征和引擎能力做针对性设计。先用 EXPLAIN 看清当前执行路径，再决定是加联合索引、建汇总表，还是换算法。
