SQL中如何使用APPROX_COUNT_DISTINCT提升超大规模统计速度技巧

先说一个容易被忽视的事实：APPROX_COUNT_DISTINCT(col) 并不是每个数据库都真正“近似”的——它背后的实现差异，可能让业务报表出现两种截然不同的命运。有的数据库原生支持 HyperLogLog 算法，几毫秒就能给出百万级 UV 的估算；有的则仅仅是个语法糖，跑起来和精确去重一样慢。下面拆开来看，每种主流数据库的坑和路。

APPROX_COUNT_DISTINCT在Oracle中怎么写才不报错

直接写 APPROX_COUNT_DISTINCT(col) 就行，但前提是 Oracle 版本 ≥ 12.1.0.2；低于这个版本会抛 ORA-00904: "APPROX_COUNT_DISTINCT": invalid identifier。它支持 GROUP BY、HA VING、ORDER BY，比如：SELECT deptno, APPROX_COUNT_DISTINCT(empno) FROM emp GROUP BY deptno。但不能嵌套（如 APPROX_COUNT_DISTINCT(COUNT(*))）、不能用窗口函数（APPROX_COUNT_DISTINCT() OVER () 会报错），也不能用于子查询的 SELECT 列表之外的上下文（比如 WHERE 中直接调用）。

为什么PostgreSQL里APPROX_COUNT_DISTINCT没效果

PostgreSQL 原生的 APPROX_COUNT_DISTINCT() 函数只是个空壳，不加速——它底层没走 HyperLogLog，执行计划和 COUNT(DISTINCT) 完全一样。真要用近似去重，必须手动启用 hll 扩展：CREATE EXTENSION hll;（需 superuser 权限）。之后建表时定义 uv_hll hll 字段，写入时用 hll_add_agg(hll_hash_bigint(user_id)) 累积，查时只调 hll_cardinality(uv_hll)。不预聚合、每次查都重建 HLL 结构，性能反而更差。

MySQL 8.0+ 的 APPROX_COUNT_DISTINCT 是不是智商税

是。MySQL 8.0+ 的 APPROX_COUNT_DISTINCT() 只是 COUNT(DISTINCT) 的同义词，执行计划、内存占用、磁盘落写行为完全一致。它不会跳过哈希表构建，也不会降低 work_mem 压力，大数据量下照样慢、照样 OOM。别被函数名误导——想提速，得换方案：要么用采样（TABLESAMPLE + 校准系数，但对倾斜数据误差爆炸），要么迁移到支持真 HLL 的引擎（如 ClickHouse 的 uniq() 或 Spark SQL 的 approx_count_distinct()）。

误差±2%到底影响哪些业务场景

误差本身稳定（实测 95% 置信度下偏差 ≤3%），但业务是否能接受，取决于指标用途：

• 报表趋势、AB 测试分流比例、DAU/MAU 估算、监控告警阈值判断——完全可用
• 合同数量核验、财务对账明细、用户退款资格判定——绝对不可用
• 注意：即使允许误差，也得确认列类型兼容——APPROX_COUNT_DISTINCT 对 BLOB、BFILE 直接报错，而 COUNT(DISTINCT) 至少还能跑（哪怕极慢）

最常被忽略的是：它返回 NUMBER 类型，但值是整数；如果下游代码做了 float 比较或小数位截断，可能引发隐式转换问题。