APPROX_COUNT_DISTINCT(col)在Oracle中直接使用即可，但要求版本≥12.1.0.2，支持GROUP BY、HAVING、ORDER BY，不支持嵌套调用、窗口函数及WHERE子句中直接使用。
APPROX_COUNT_DISTINCT在Oracle中怎么写才不报错
直接写 APPROX_COUNT_DISTINCT(col) 就行，但前提是 Oracle 版本 ≥ 12.1.0.2；低于这个版本会抛 ORA-00904: "APPROX_COUNT_DISTINCT": invalid identifier。它支持 GROUP BY、HAVING、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 比较或小数位截断，可能引发隐式转换问题。
