在SQL查询中，统计指定字段的不重复值总数是数据分析、业务统计场景下的高频需求。无论是统计去重后的用户数、订单涉及的城市数，还是计算不同商品类目的数量，往往都需要从大量重复数据中提取唯一值的个数。COUNT(DISTINCT column) 是SQL标准中提供的直接实现方式，能够在一条查询中完成去重与计数，因此被广泛应用于各类报表和指标计算中。
COUNT(DISTINCT column)基础用法
COUNT(DISTINCT column) 的语法结构非常直观，核心是在聚合函数 COUNT 内部添加 DISTINCT 关键字，表示对指定列先进行去重，然后再统计去重后的记录数量。下面是一个最基本的查询示例，用于统计用户信息表中出现了多少个不同的城市：
-- 统计用户表中不重复的城市数量 SELECT COUNT(DISTINCT city) AS distinct_city_count FROM user_info;
从执行结果来看，如果 city 列中有三个城市且某些城市重复出现，最终返回的就是城市类别的数量，而不是记录总行数。需要注意的是，DISTINCT 只能作用于单个列名，不能直接写成 COUNT(DISTINCT col1, col2) 来统计多列组合的去重值，否则数据库会报告语法错误。多列组合去重需要采用拼接或分组的方式另行实现。
另外，COUNT(DISTINCT column) 会自动忽略列为 NULL 的记录，与普通 COUNT(column) 的行为保持一致。这意味着在执行去重统计时，NULL 值既不会计入去重结果，也不会因为多个 NULL 而影响返回数量。在实际业务中，如果目标列存在较多空值，统计结果可能低于总记录数，这是正常现象。
COUNT(DISTINCT column)的性能损耗原因
在数据量较小的表中，COUNT(DISTINCT column) 的执行耗时通常可以忽略不计，但是当表规模达到千万行甚至亿行时，这条看似简单的查询往往会成为性能瓶颈。性能下降主要来自两个方面的原因。
- 去重操作需要额外的内存和计算资源：数据库在执行
DISTINCT时，必须把参与统计的列值全部读取到内存中，再通过哈希表或排序等方式完成去重。如果唯一值数量很大，内存无法容纳全部去重结果，数据库会退化为使用磁盘临时表，带来大量的磁盘 IO 开销，查询速度会明显下降。 - 无法有效利用普通索引：大部分数据库的普通 B+ 树索引并不能被
COUNT(DISTINCT)直接用于去重计数，因为索引中存储的是有序的完整键值，而要去重统计仍然需要扫描所有键值才能确定唯一性。这样一来，查询往往需要执行全表扫描或者全索引扫描，数据量越大，扫描成本越高，执行时间也越长。
了解这两个原因后，就能更有针对性地选择优化方案。在评估优化手段时，需要同时考虑数据规模、查询频率以及业务对精度的要求，而不是一味更换写法。
大数据量下的优化方案
针对 COUNT(DISTINCT column) 的性能问题，业界常用的优化思路包括使用近似去重函数、提前预计算结果以及拆分批次统计后再合并。这三种方案各有优劣，适用于不同的业务场景。
方案一：使用近似去重计数函数
如果业务能够容忍细微的统计误差，可以考虑使用数据库提供的近似去重计数函数。例如 MySQL 提供的 APPROX_COUNT_DISTINCT，PostgreSQL 也可以通过 hyperloglog 等扩展实现类似能力。这类函数基于概率数据结构进行唯一值估计，内存占用极低，执行速度通常比精确去重快数倍到数十倍，误差往往控制在 1% 以内。
-- MySQL中使用近似去重计数函数 SELECT APPROX_COUNT_DISTINCT(city) AS approx_distinct_city_count FROM user_info;
该方案特别适合实时看板、流量统计等允许轻微误差的报表场景。如果业务要求绝对精确，则不应选择近似函数，而应继续使用精确去重或采用预计算方式。
方案二：提前预计算去重结果
对于固定维度的重复统计需求，例如每天都要查询全表不重复城市数、不重复会员数等，可以在数据写入时或者通过定时任务提前计算去重值，并把结果保存到单独的汇总表。查询时直接读取汇总表的一行结果，避免了每次请求都触发昂贵的去重操作。
预计算的核心思想是用写入或调度阶段的一次性开销，替代查询阶段的大量重复计算。它的优点是查询响应极快，缺点是需要维护额外的汇总表和调度任务，并且汇总数据可能存在一定延迟。因此，预计算适合统计口径稳定、查询频率高、对延迟不敏感的场景。
方案三：分批次统计后合并
当表的数据量过于庞大，即使使用预计算也难以一次完成时，可以按照时间、地区、业务线等维度将数据拆分成多个子集，分别统计每个子集的去重结果，然后再进行合并。比如先统计每个月的去重城市数，再将十二个月的结果合并得到全年的去重城市数量。合并时需要注意跨月的重复值，如果两个子集存在相同的城市，直接相加会得到重复计数，因此通常需要在应用层或数据库外做二次去重。
这种方案的核心优势在于可以削减单次去重的数据规模，降低内存和磁盘压力，使任务更容易执行。但它的复杂度较高，需要额外的分区逻辑和合并逻辑，一般只在超大规模数据仓库或离线计算任务中使用。
使用注意事项总结
综合来看，COUNT(DISTINCT column) 本身不是问题，它的问题在于面对大数据量时的资源消耗和扫描成本。实际工作中，应当根据数据规模与业务要求选择合适方案。对于数据量较小、查询频率不高的场景，直接使用 COUNT(DISTINCT column) 是最简单、最可靠的方式；对于大数据量且允许误差的分析场景，可以优先考虑近似去重函数；对于固定统计口径的频繁查询，建议提前把去重结果预计算到汇总表。
还需要特别注意的是，COUNT(DISTINCT) 不支持多列组合去重。如果业务需要统计多个列组合后的唯一值数量，可以采用两种替代方案。第一种是先用拼接函数将多列合并为一个字符串，再去重统计；第二种是使用子查询先对多列进行 GROUP BY，然后在外层统计分组数量。下面给出这两种实现的示例：
-- 多列组合去重的替代实现：先拼接字段再统计
SELECT COUNT(DISTINCT CONCAT(col1, '_', col2)) AS distinct_combine_count
FROM test_table;
-- 或者先对多列分组，再统计分组数量
SELECT COUNT(*) AS distinct_combine_count
FROM (
SELECT col1, col2
FROM test_table
GROUP BY col1, col2
) t;
总之，COUNT(DISTINCT column) 是统计不重复值的标准手段，理解它的工作方式和性能边界，才能在适合的场合使用它，并在大数据量下采用更高效的替代方案
在实际工程中，COUNT(DISTINCT column) 的行为还会受到具体数据库实现和查询优化器的影响。例如在 MySQL 中，InnoDB 引擎无法直接利用索引来优化 COUNT(DISTINCT) 的扫描过程，即使列上有二级索引，也往往需要回表或全索引扫描，这与 COUNT(*) 的优化路径完全不同。而在 PostgreSQL 中，优化器可能会将 COUNT(DISTINCT) 转换为 HashAggregate 或 GroupAggregate 计划，面对大数据量时同样面临内存不足的问题。
在 Hive 和 Spark SQL 这类分布式计算框架中，COUNT(DISTINCT) 的代价更加特殊。默认情况下，Hive 会把 COUNT(DISTINCT) 整个计算压到一个 Reduce 任务中，造成严重的数据倾斜和单点瓶颈。为了解决这个问题，通常需要手动设置参数，例如启用 hive.optimize.countdistinct 或使用 GROUP BY 加去重的方式将计算分散到多个 Reduce 中。Spark SQL 则会将 COUNT(DISTINCT) 翻译为 expand 加 aggregate 算子，虽然可以并行，但当需要同时对多个列进行去重计数时，expand 可能会产生大量中间数据，影响性能。因此，在分布式环境下，简单的 SQL 写法往往不如显式拆分任务来得高效。
另一个容易忽略的细节是 COUNT(DISTINCT) 与 GROUP BY 同时使用时的语义。例如下面的查询希望统计每个部门中的不同岗位数量：
SELECT dept_id, COUNT(DISTINCT job_id) AS distinct_jobs FROM employee GROUP BY dept_id;
这种写法本身没有问题，但如果业务还要统计总人数、总 Distinct 值等，有时会倾向于在一个查询中完成所有聚合，导致 SQL 复杂度上升，优化器难以生成高效计划。更稳妥的做法是拆分多个聚合查询，或者使用窗口函数配合条件聚合，避免单个聚合操作承担过多不同语义的去重责任。
此外，对于高基数列（例如用户 ID、订单号、设备指纹等），COUNT(DISTINCT) 的内存消耗往往被低估。一个简单估算：如果列值平均长度为 32 字节，数据量为 1 亿行，去重时需要维护的哈希表会占用数 GB 内存，这在一台普通的数据库服务器上已经非常吃力。因此，即使是使用近似去重函数，也需要根据业务可接受的误差范围选择合适的精度参数，避免为了追求绝对精确而牺牲整体稳定性。
在面试和实际优化工作中，还经常会遇到“如何统计 UV、去重用户数、不同商品数”等问题。这时除了直接使用 COUNT(DISTINCT)，还可以考虑使用 Bitmap、HyperLogLog 等数据结构，在数据写入阶段就完成预聚合。例如在实时数仓中，通过 Flink 或 Spark Streaming 将用户访问事件按分钟或小时聚合，用 Bitmap 保存用户 ID 集合，查询时再合并 Bitmap 并求基数，可以极大降低实时查询的延迟和资源消耗。
总结来看，COUNT(DISTINCT column) 是一个语义清晰但代价可能很高的操作。理解它的执行机制、优化路径和替代方案，是 SQL 性能调优中不可回避的一环。在数据量小、逻辑简单时，直接使用它是最自然的选择；当数据量增长到单机无法承受、或者查询频繁且延迟敏感时，就需要主动考虑近似算法、预计算、任务拆分等手段。技术选型的本质是在准确度、时效性、资源成本和开发复杂度之间做权衡，而 COUNT(DISTINCT) 正是这种权衡的一个典型缩影。
希望本文能够帮助你更全面地认识 COUNT(DISTINCT)，并在后续的开发和优化工作中做出更合理的决策。
SQLCOUNT_DISTINCT不重复值统计数据库性能优化修改时间：2026-07-14 20:54:22