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 = '2024-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抽样验证数据分布，避免倾斜
