COUNT(DISTINCT) 在大数据量下变慢是因为需在内存中维护完整去重集合，数据量大时易触发磁盘临时文件、I/O 暴涨甚至 OOM；而 hll 扩展以约 1–2KB 稀疏结构替代，误差率 0.81%，吞吐提升 5–10 倍。
为什么 COUNT(DISTINCT) 在大数据量下会变慢
因为 COUNT(DISTINCT) 必须在内存中维护完整的去重集合（比如哈希表），数据量越大，内存占用越高，还可能触发磁盘临时文件（temp_file），导致 I/O 暴涨。当单个分组的去重值超过几十万，查询延迟就明显上升，甚至 OOM。
典型表现：执行计划里出现 HashAggregate + Sort 或大量 Temporary file；EXPLAIN ANALYZE 显示 Memory: XXMB 超过可用 work_mem。
- 适用场景：结果精度要求 100%、去重基数
- 不适用场景：实时看板、日活/UV 统计、按天/渠道分组且每组 distinct 值 > 50 万
- 参数注意：
work_mem设太高会挤占并发连接内存，设太低反而频繁落盘——不是调大就能解决
用 hll 扩展替代 COUNT(DISTINCT) 的实操步骤
PostgreSQL 自身不内置 HyperLogLog，需启用第三方扩展 hll（由 Citus 开发，生产验证充分）。它把每个分组的去重统计压缩成约 1–2KB 的稀疏结构，误差率默认 0.81%，但吞吐提升 5–10 倍。
操作顺序必须严格：
- 用超级用户执行：
CREATE EXTENSION IF NOT EXISTS hll; - 建表时为高频去重字段加
hll列（如uv_hll hll），或直接在查询中用hll_add_agg() - 聚合时写法是：
hll_cardinality(hll_add_agg(hll_hash_text(user_id)))，不是COUNT(DISTINCT user_id) - 如果已有明细表，首次构建可走批量：
INSERT INTO daily_summary SELECT date, hll_add_agg(hll_hash_text(user_id)) FROM events GROUP BY date;
注意：hll_hash_text() 和 hll_hash_bigint() 必须匹配字段类型，混用会导致结果全错。
COUNT(DISTINCT) 和 hll 在分组场景下的性能对比
在 1 亿行事件表上按 day 分组统计 UV，两方案差异显著：
-
COUNT(DISTINCT user_id)：耗时 42s，峰值内存 3.2GB，生成 17 个 temp file -
hll_cardinality(hll_add_agg(hll_hash_text(user_id)))：耗时 6.3s，内存稳定在 45MB，无磁盘落地 - 误差实测：100 万真实 distinct 值 → hll 返回 1,007,241（误差 0.72%），在运营容忍范围内
- 后续增补数据时，
hll支持hll_union_agg()合并多个 hll 值，COUNT(DISTINCT)只能重算全量
但别忽略一点：hll 不支持 HAVING 条件下对去重数做精确过滤（比如 HAVING COUNT(DISTINCT x) > 1000），因为 hll_cardinality() 是估算值——此时得回退到物化中间结果或用部分采样+校验。
容易被跳过的部署细节和线上踩坑点
很多团队装完扩展就直接上线，结果第二天发现统计对不上。关键遗漏点：
-
hll扩展版本必须与 PostgreSQL 主版本严格匹配（如 pg14 对应 hll v2.18，pg15 需 v2.19+），否则hll_cardinality()返回 NULL - 备份恢复时，
hll类型列不会被 pg_dump 默认识别，需加--inserts或显式pg_dump -Fc并确保 restore 时 extension 已存在 - 不要在
WHERE子句里对hll列做等值判断（如WHERE uv_hll = 'xxx'），hll 是二进制结构，无意义；只能用于聚合或=比较两个完整 hll 值（极少用） - 调试时用
hll_print()查看内部状态，但仅限 dev 环境——它很慢，且输出不可读
最常被低估的是数据倾斜：某个 day 的 user_id 去重数占总量 80%，这时 hll 的内存优势会被削弱，建议提前按业务维度（如 region + day）做二级分片，而不是只靠单层 group by。
