APPROX_COUNT_DISTINCT 是基于 HyperLogLog 的确定性近似算法，内存恒定、天然并行、误差±2%以内；它绕开 COUNT(DISTINCT) 的哈希膨胀与磁盘落写瓶颈，适用于报表监控等精度容忍场景，但不支持窗口函数和嵌套调用。
APPROX_COUNT_DISTINCT 不是“差不多就行”的妥协，而是用确定性算法换掉哈希表膨胀和排序开销——在超大规模数据下，它直接绕开了 COUNT(DISTINCT) 最致命的两个瓶颈：内存爆炸和磁盘落写。
为什么 COUNT(DISTINCT) 在大数据量下会突然变慢
执行 COUNT(DISTINCT col) 时，Oracle 必须把所有非 NULL 的 col 值读出来，再用哈希或排序去重。当数据量上亿、去重后基数（distinct 值个数）也达千万级时：
- 哈希表无法全驻内存，
hash_area_size或work_mem不足会强制写临时表，I/O 成倍增加 - 即使有索引，也不能跳过重复值扫描——索引只加速定位，不加速去重逻辑
- 并行执行时各进程需合并哈希状态，跨节点通信开销显著
APPROX_COUNT_DISTINCT 怎么避开这些坑
它底层用的是 HyperLogLog（HLL）类概率算法，核心是「用固定大小的稀疏寄存器记录值分布特征」，而非存储原始值：
- 内存占用恒定：无论输入 100 万还是 10 亿行，内部结构通常只占几 KB 到几十 KB
- 天然支持并行：每个并行进程各自维护本地 HLL 结构，最后 merge 寄存器即可，无状态同步成本
- 忽略 NULL 值的行为与
COUNT(DISTINCT)一致，语义兼容 - 对
BFILE、BLOB等大对象类型不支持，但这是明确限制，不是运行时崩溃
误差到底有多大？业务敢不敢用
Oracle 官方未公开误差公式，但实测和第三方测试（如 Christian Antognini）表明：
- 相对误差通常稳定在 ±2% 以内，95% 置信度下可达 97% 准确率
- 数据越分散（high cardinality），相对误差反而越小；数据高度倾斜（如 90% 值重复）时，误差可能略升，但仍远低于 5%
- 报表、监控、AB 测试、用户活跃度趋势分析等场景，这个精度完全可用；但财务对账、合同数量核验等必须精确的环节，不能替代
COUNT(DISTINCT) - 注意：它返回
NUMBER类型，但值是整数，不会出现小数
实际写法和常见踩坑点
语法简单，但几个细节极易被忽略：
- 仅 Oracle 12.1.0.2+ 支持，低版本会报错
ORA-00904: "APPROX_COUNT_DISTINCT": invalid identifier - 可与
GROUP BY、ORDER BY混用，例如：SELECT deptno, APPROX_COUNT_DISTINCT(empno) FROM emp GROUP BY deptno - 不能嵌套使用，如
APPROX_COUNT_DISTINCT(COUNT(*))是非法的 - 和窗口函数不兼容，
APPROX_COUNT_DISTINCT() OVER (...)会报错 - 如果列存在大量 NULL，虽然函数自动忽略，但要注意：这和你业务中“是否该计入 NULL”是否一致
真正关键的不是“快多少”，而是它把资源消耗从随数据量线性/超线性增长，拉平为常量级——这意味着你不再需要为某张日增 5 亿行的表单独扩容 PGA，也不用担心某次报表查询把临时表空间打爆。只要业务能接受 ±2% 的波动，它就不是备选方案，而是默认选项。
