COUNT(DISTINCT...)在海量数据下易成瓶颈，主因是触发临时表和文件排序；优化需避免全量去重扫描，优先走索引、用GROUP BY替代、采样估算、预计算或分表。
MySQL 中的 COUNT(DISTINCT ...) 在海量数据下容易成为性能瓶颈，不是因为它“不能用”，而是默认执行方式会触发临时表、文件排序甚至磁盘临时表。高效去重统计的关键在于**避免全量去重扫描**，转而通过索引优化、分步聚合、近似算法或架构层面拆解来缓解压力。
优先走索引，避免全表扫描
如果去重字段上有合适索引（尤其是唯一索引或前缀索引），MySQL 可能利用索引的有序性跳过排序阶段，直接遍历索引完成计数。例如：
- 对主键或唯一键做
COUNT(DISTINCT id)，通常极快（等价于COUNT(*)）； - 对高频低基数字段（如
status、country_code）建普通索引后，配合WHERE条件可显著减少扫描行数； - 避免在无索引字段（如长文本、JSON 字段）上直接
COUNT(DISTINCT)，否则必走全表 + 内存/磁盘临时表。
用 GROUP BY + COUNT(*) 替代（适合中等规模）
当去重维度明确且基数可控时，先 GROUP BY 再计数，有时比 COUNT(DISTINCT) 更易命中索引和利用缓存：
SELECT COUNT(*) FROM (SELECT DISTINCT user_id FROM orders WHERE created_at > '2024-01-01') t;- 相比
SELECT COUNT(DISTINCT user_id) FROM orders WHERE created_at > '2024-01-01';，子查询形式更可能复用已有的(created_at, user_id)联合索引； - 注意：若去重后结果集过大（如千万级不同值），子查询仍会生成大临时表，此时不推荐。
采样估算或 HyperLogLog 近似统计（超大数据量）
当业务允许少量误差（如运营看板、实时监控），可用概率算法替代精确去重：
- MySQL 8.0+ 原生不支持 HyperLogLog，但可通过应用层实现：比如用 Redis 的
PFCOUNT预聚合用户 ID； - 对日志类宽表，先用
WHERE + LIMIT采样 1% 数据，再用COUNT(DISTINCT)估算总量（需校正偏差）； - 更稳妥的做法是将去重逻辑前置：写入时用 Kafka + Flink 实时维护
user_id的布隆过滤器或 HLL 结构，查询直取近似值。
分库分表或预计算汇总表（长期方案）
对核心业务指标（如“每日活跃用户数”），不要每次实时算：
- 建立汇总表
daily_active_users(dt DATE, cnt BIGINT, uniq_users TEXT)，每天凌晨用定时任务跑一次去重并写入； - 按时间/租户分表（如
orders_202401），查询时只查目标分区，大幅缩小数据范围； - 使用 MySQL 8.0 的不可见列 + 生成列，在写入时自动提取关键去重字段并建索引，降低查询侧负担。
不复杂但容易忽略：检查 EXPLAIN FORMAT=TREE 输出中的 Using temporary; Using filesort，这是性能告警信号；同时调大 tmp_table_size 和 max_heap_table_size（需权衡内存），让临时表尽量留在内存中。
