COUNT(DISTINCT)在EXPLAIN中显示Using temporary，是因为数据库必须为每个分组（或全表）维护哈希表或排序缓冲区去重，属独立计算阶段；高基数字段易耗尽tmp_table_size，触发磁盘临时文件，导致响应跳变；MySQL 8.0+哈希聚合仅在未混用GROUP BY或子查询时生效。
为什么COUNT(DISTINCT)总在EXPLAIN里显示Using temporary？
因为数据库必须为每个分组（或全表）维护一个哈希表或排序缓冲区来去重，COUNT(DISTINCT)不是修饰符，而是独立的计算阶段。当字段基数高（比如千万级user_id），这个结构会迅速吃光tmp_table_size，触发磁盘临时文件，响应时间跳变。MySQL 8.0+虽支持哈希聚合，但一旦混用GROUP BY或子查询，立刻退化回排序路径。
APPROX_COUNT_DISTINCT()真能替代？哪些场景不适用？
可以，但要看精度容忍度和引擎版本：
- MySQL 8.0.17+ 支持
APPROX_COUNT_DISTINCT()（基于HyperLogLog），误差率约0.8%，内存开销恒定 O(1)，千万行耗时稳定在200ms内 - PostgreSQL 需用
approx_count_distinct()（需安装postgresql-contrib）或原生pg_statistic估算 - 不适用：财务对账、合规审计、阈值告警（如“活跃用户跌破10万”）——近似值无法用于精确判断
- 注意：
APPROX_COUNT_DISTINCT()仍会忽略NULL，这点和COUNT(DISTINCT)一致，无需额外适配
用汇总表预计算时，如何避免数据延迟和双写不一致？
靠触发器或应用层双写极易出错。推荐以下组合：
- 用
INSERT ... ON DUPLICATE KEY UPDATE或MERGE（PostgreSQL/SQL Server）原子更新计数器，主键设为分组键（如dept_id） - 汇总表字段至少包含：
group_key、distinct_count、last_updated、row_version - 每日凌晨跑校验脚本：
SELECT COUNT(DISTINCT user_id) FROM fact_orders WHERE date >= CURDATE() - INTERVAL 1 DAY对比汇总值，偏差>0.1%则自动重刷 - 禁止直接查源表做
COUNT(DISTINCT)——哪怕加了WHERE条件，只要没覆盖索引，依然全表扫描
JOIN后统计唯一主表ID，为什么不能先DISTINCT再COUNT？
写成 SELECT COUNT(*) FROM (SELECT DISTINCT users.id FROM users LEFT JOIN orders ...) 看似合理，实则灾难：
- 子查询强制物化全部中间结果，50万行JOIN结果全落地临时表，哪怕外层只
LIMIT 1 -
DISTINCT在子查询里关闭所有谓词下推，WHERE users.status = 'active'被拖到物化之后才执行 - 正确做法是把
COUNT(DISTINCT users.id)直接写在外层，让优化器有机会利用users.id上的索引做半连接（semi-join）优化 - 若
users.id是主键且非空，COUNT(DISTINCT users.id)≡COUNT(users.id)，可直接降级为普通COUNT()
真正难处理的是跨天窗口+实时性要求高的去重统计——这时候哈希表内存压力、NULL语义、以及分布式环境下分片键与去重键不一致，三个问题会同时爆发。
