DISTINCT是行级去重而非聚合操作，实现聚合去重需用GROUP BY或窗口函数；盲目使用易致性能瓶颈，应结合索引、覆盖索引、EXISTS或近似函数优化。
SQL中用DISTINCT去重本身不聚合，真正实现“聚合去重”需结合GROUP BY或窗口函数；盲目依赖DISTINCT易引发性能瓶颈，尤其在大数据量、多字段、无索引场景下。
DISTINCT是行级去重，作用于查询结果集整体，不支持计算逻辑；而聚合去重（如“每个用户最新订单ID”、“每类商品去重后的平均价格”）必须用GROUP BY配合聚合函数（MAX()、AVG()、COUNT(DISTINCT ...)等）。常见误区是写SELECT DISTINCT a, MAX(b) FROM t GROUP BY a——语法虽可能通过，但语义混乱，MAX(b)实际由GROUP BY决定，DISTINCT冗余且拖慢执行。
结合索引、覆盖索引、EXISTS或近似函数优化。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时，通常需对目标字段做排序（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)，避免回表当原始表极大，但去重后结果集很小（例如千万级日志中只涉及几百个活跃用户），可先用高效子查询缩小范围，再对小结果集去重，比全表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)是典型高开销操作，尤其字段基数大（如用户ID）、内存不足时会落盘。部分数据库提供近似函数（如PostgreSQL的APPROX_COUNT_DISTINCT，Spark SQL的approx_count_distinct），误差率可控（通常
innodb_stats_persistent并更新统计信息，让优化器更准选择执行计划COUNT(DISTINCT)前，先用SAMPLE抽样验证数据分布，避免倾斜