SQL分组统计去重时COUNT DISTINCT有哪些优化思路

在SQL数据处理场景中，我们经常需要对数据进行分组后统计去重后的数量，这时候通常会用到COUNT DISTINCT语法。但随着数据量增长，这类查询的执行效率会明显下降，甚至出现查询超时的问题，因此需要针对性的优化思路来提升性能。

COUNT DISTINCT的性能问题根源

COUNT DISTINCT需要在分组的基础上对指定字段进行去重计数，数据库执行时需要维护去重集合，当数据量较大或者分组数量较多时，会占用大量内存和计算资源，导致查询速度变慢。尤其是在没有合适索引支撑的情况下，全表扫描加去重计算的开销会成倍增加。

常见优化思路

1. 子查询提前去重

如果直接对原表进行分组加COUNT DISTINCT，数据库需要处理大量重复数据。可以先通过子查询对需要去重的字段提前去重，再进行分组统计，减少后续计算的数据量。

假设我们有订单表order_info，需要统计每个用户下不同商品的数量，原查询如下：

-- 原查询，直接分组后去重计数
SELECT user_id, COUNT(DISTINCT goods_id) AS goods_count
FROM order_info
GROUP BY user_id;

优化后的子查询去重方案：

-- 先去重再分组统计
SELECT user_id, COUNT(goods_id) AS goods_count
FROM (
    SELECT DISTINCT user_id, goods_id
    FROM order_info
) AS tmp
GROUP BY user_id;

2. 使用临时表存储去重数据

当数据量特别大时，子查询的中间结果可能依然占用较多资源，这时候可以将去重后的数据存储到临时表中，再基于临时表做分组统计，临时表还可以根据需要创建索引进一步提升查询速度。

-- 创建临时表存储去重数据
CREATE TEMPORARY TABLE tmp_order_distinct AS
SELECT DISTINCT user_id, goods_id
FROM order_info;

-- 给临时表创建索引
CREATE INDEX idx_user_id ON tmp_order_distinct(user_id);

-- 基于临时表统计
SELECT user_id, COUNT(goods_id) AS goods_count
FROM tmp_order_distinct
GROUP BY user_id;

-- 使用完可以删除临时表
DROP TEMPORARY TABLE tmp_order_distinct;

3. 调整统计逻辑适配业务场景

有些业务场景下，COUNT DISTINCT的统计结果可以通过其他逻辑替代，比如如果业务只需要近似去重计数，可以使用数据库内置的近似计算函数，比如MySQL的APPROX_COUNT_DISTINCT，PostgreSQL的hyperloglog扩展，这类函数计算速度快，适合对精度要求不高的场景。

-- MySQL中使用近似去重计数函数
SELECT user_id, APPROX_COUNT_DISTINCT(goods_id) AS goods_count
FROM order_info
GROUP BY user_id;

4. 建立合适的联合索引

如果查询中分组字段和去重字段是固定的，可以建立对应的联合索引，让数据库可以直接利用索引完成去重和分组操作，避免全表扫描。

比如上述统计用户不同商品数量的场景，可以建立idx_user_goods联合索引：

-- 创建联合索引
CREATE INDEX idx_user_goods ON order_info(user_id, goods_id);

建立索引后，数据库可以直接通过索引获取去重后的user_id和goods_id组合，大幅提升查询效率。

不同优化方案的选择建议

如果数据量较小，子查询提前去重的方案改动最小，适配性最好；数据量中等时可以结合临时表和索引使用；如果对统计精度要求不高，近似计数函数是最优选择；如果查询是高频使用的固定逻辑，建立联合索引可以从根本上提升性能。实际优化时可以根据数据量、业务精度要求、查询频率这几个维度综合选择方案。

SQLCOUNT_DISTINCT分组统计查询优化修改时间：2026-07-17 07:54:24