DISTINCT是行级去重而非聚合操作，实现聚合去重需用GROUP BY或窗口函数；盲目使用易致性能瓶颈，应结合索引、覆盖索引、EXISTS或近似函数优化。

SQL中用DISTINCT去重本身不聚合，真正实现“聚合去重”需结合GROUP BY或窗口函数；盲目依赖DISTINCT易引发性能瓶颈，尤其在大数据量、多字段、无索引场景下。

明确DISTINCT不是聚合操作，别和GROUP BY混用

DISTINCT是行级去重，作用于查询结果集整体，不支持计算逻辑；而聚合去重（如“每个用户最新订单ID”、“每类商品去重后的平均价格”）必须用GROUP BY配合聚合函数（MAX()、AVG()、COUNT(DISTINCT ...)等）。常见误区是写SELECT DISTINCT a, MAX(b) FROM t GROUP BY a——语法虽可能通过，但语义混乱，MAX(b)实际由GROUP BY决定，DISTINCT冗余且拖慢执行。

• 要统计“不同城市数量”，用COUNT(DISTINCT city)，不是SELECT DISTINCT city FROM t; COUNT(*)
• 要取“每个部门薪资最高的员工”，用GROUP BY dept_id + MAX(salary)，或搭配窗口函数ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)
• 避免SELECT DISTINCT *：字段越多，排序/哈希去重开销越大；只选必要列

用索引加速DISTINCT和GROUP BY的底层排序/哈希

数据库执行DISTINCT或GROUP BY时，通常需对目标字段做排序（Sort-Based）或构建哈希表（Hash-Based）。若对应字段有合适索引，可跳过排序阶段，直接顺序扫描+去重，性能提升显著。

• 单字段去重：SELECT DISTINCT status FROM orders → 在status上建普通索引
• 多字段组合去重：SELECT DISTINCT user_id, product_id FROM clicks → 建联合索引(user_id, product_id)，顺序不能颠倒（前导列需匹配查询条件）
• 注意覆盖索引：若SELECT DISTINCT a, b FROM t WHERE c = 1，可建索引(c, a, b)，避免回表

替代方案：用EXISTS或窗口函数减少数据量再DISTINCT

当原始表极大，但去重后结果集很小（例如千万级日志中只涉及几百个活跃用户），可先用高效子查询缩小范围，再对小结果集去重，比全表DISTINCT快得多。

• 代替SELECT DISTINCT user_id FROM events WHERE dt = '2025-01-01'，若已有分区表按dt分区，该语句本身已高效；否则可加WHERE user_id IS NOT NULL过滤空值，减少参与去重的数据量
• 需要“每个用户最近一次登录时间”，不用SELECT DISTINCT user_id, MAX(login_time)（仍需全量分组），改用窗口函数：SELECT user_id, login_time FROM (SELECT user_id, login_time, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_time DESC) rn FROM logins) t WHERE rn = 1
• 用EXISTS去重关联：比如查“购买过A类商品的用户”，用SELECT DISTINCT u.id FROM users u WHERE EXISTS (SELECT 1 FROM orders o JOIN order_items i ON o.id=i.order_id WHERE o.user_id=u.id AND i.category='A')，比IN或JOIN + DISTINCT更可控

COUNT(DISTINCT)特别优化：注意精度与估算权衡

COUNT(DISTINCT)是典型高开销操作，尤其字段基数大（如用户ID）、内存不足时会落盘。部分数据库提供近似函数（如PostgreSQL的APPROX_COUNT_DISTINCT，Spark SQL的approx_count_distinct），误差率可控（通常

• 报表类场景（如“DAU估算”）优先用近似计数，无需精确到个位
• MySQL 8.0+ 可开启innodb_stats_persistent并更新统计信息，让优化器更准选择执行计划
• Hive/Spark中，对超大表做COUNT(DISTINCT)前，先用SAMPLE抽样验证数据分布，避免倾斜