SQL去重技术全解析：从DISTINCT到窗口函数实战

1. 为什么SQL去重是个技术活？

我刚入行时以为数据去重就是简单加个DISTINCT，直到有次处理千万级用户行为数据时，一个不加思考的DISTINCT让查询跑了40分钟才超时退出。后来才明白，不同场景下的去重需要完全不同的技术方案。

数据去重本质上要解决三个核心问题：

• 如何定义"重复"（是整行完全相同，还是特定字段组合相同）
• 处理规模对性能的影响（100条vs 1亿条）
• 去重后的数据去向（直接展示/写入新表/更新原表）

2. 基础去重方案与隐藏陷阱

2.1 DISTINCT的局限性

sql复制-- 最基础的去重方式
SELECT DISTINCT user_id, product_id FROM orders;

这个看似简单的语法有三大暗坑：

1. 性能黑洞：当SELECT字段包含大文本字段时，DISTINCT会进行全字段比对
2. 结果不可控：不同数据库对NULL值的处理不一致（有的视为相同，有的视为不同）
3. 统计失真：某些场景下DISTINCT会改变聚合结果（如COUNT DISTINCT与COUNT的差异）

实战建议：在MySQL中，DISTINCT默认使用filesort，数据量超过sort_buffer_size时会转为磁盘临时表，建议添加合适的索引或改用GROUP BY

2.2 GROUP BY的进阶用法

sql复制-- 更高效的去重写法（多数数据库优化器会特殊处理）
SELECT user_id, product_id 
FROM orders 
GROUP BY user_id, product_id;

相比DISTINCT，GROUP BY的优势在于：

• 可以利用索引优化（如果group by字段有索引）
• 方便结合HAVING进行二次过滤
• 能同时计算聚合值（如MAX(create_time)获取最新记录）

3. 高级去重技术：窗口函数实战

当需要基于特定规则保留"最新"或"最优"记录时，ROW_NUMBER()才是终极武器。

3.1 保留每个用户最近3次购买记录

sql复制WITH ranked_orders AS (
  SELECT 
    *,
    ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn
  FROM orders
)
SELECT * FROM ranked_orders WHERE rn <= 3;

这个方案的亮点在于：

1. PARTITION BY定义去重维度（相当于GROUP BY）
2. ORDER BY决定保留哪些记录（时间倒序=保留最新）
3. 最终筛选条件灵活可控（rn<=3表示保留Top3）

3.2 复杂业务规则去重案例

假设需要找出每个商品品类中价格最低但评分最高的记录：

sql复制WITH product_stats AS (
  SELECT 
    product_id,
    category,
    price,
    AVG(rating) AS avg_rating,
    -- 价格升序排名
    ROW_NUMBER() OVER (PARTITION BY category ORDER BY price ASC) AS price_rank,
    -- 评分降序排名
    ROW_NUMBER() OVER (PARTITION BY category ORDER BY AVG(rating) DESC) AS rating_rank
  FROM products
  GROUP BY product_id, category, price
)
SELECT * FROM product_stats 
WHERE price_rank = 1 AND rating_rank = 1;

4. 超大规模数据去重优化

当表数据超过1亿行时，需要特殊处理技巧：

4.1 分批处理技术

sql复制-- 按ID范围分批处理（适合有自增ID的表）
CREATE TABLE deduplicated_data AS
SELECT * FROM source_table WHERE 1=0;

BEGIN;
INSERT INTO deduplicated_data
SELECT DISTINCT * FROM source_table 
WHERE id BETWEEN 1 AND 1000000;
COMMIT;

-- 重复执行直到覆盖全表

4.2 临时表+并行处理

sql复制-- 步骤1：创建带索引的临时表
CREATE TEMPORARY TABLE temp_dedup (
  LIKE source_table INCLUDING INDEXES
);

-- 步骤2：并行插入（不同会话处理不同数据分片）
-- 会话1：
INSERT INTO temp_dedup
SELECT * FROM source_table TABLESAMPLE BERNOULLI(10) 
WHERE hash_key % 4 = 0;

-- 会话2：
INSERT INTO temp_dedup
SELECT * FROM source_table TABLESAMPLE BERNOULLI(10)
WHERE hash_key % 4 = 1;
-- ...其余分片

-- 步骤3：合并结果
CREATE TABLE final_result AS
SELECT DISTINCT * FROM temp_dedup;

5. 特殊数据类型去重技巧

5.1 JSON字段去重

sql复制-- PostgreSQL示例：标准化JSON后去重
SELECT DISTINCT 
  jsonb_strip_nulls(jsonb_normalize(json_data)) 
FROM json_table;

-- MySQL 8.0+：使用JSON_STABLE_HASH
SELECT DISTINCT 
  JSON_STABLE_HASH(json_data)
FROM json_table;

5.2 地理空间数据去重

sql复制-- PostGIS示例：5米范围内视为重复点
SELECT DISTINCT ON (ST_ClusterDBSCAN(geom, 5, 1) OVER ()) *
FROM locations;

6. 去重性能对比测试

我在AWS r5.2xlarge实例上测试了不同方法的性能（1亿行数据）：

*分批处理总时间约150s，但单批资源消耗低，适合内存受限环境

7. 常见业务场景解决方案

7.1 用户画像去重

sql复制-- 合并同一用户的多来源画像（保留最新非空值）
SELECT 
  user_id,
  FIRST_VALUE(name) OVER (PARTITION BY user_id ORDER BY 
    CASE WHEN name IS NOT NULL THEN 0 ELSE 1 END,
    update_time DESC) AS final_name,
  -- 其他字段同理...
FROM user_profiles;

7.2 日志数据去重

sql复制-- 对相似日志去重（相同URL+相同错误码+5分钟内视为重复）
SELECT 
  log_time,
  url,
  error_code,
  message
FROM (
  SELECT 
    *,
    LAG(error_code) OVER (PARTITION BY url ORDER BY log_time) AS prev_error,
    LAG(log_time) OVER (PARTITION BY url ORDER BY log_time) AS prev_time
  FROM server_logs
) t
WHERE error_code IS DISTINCT FROM prev_error
   OR log_time - prev_time > INTERVAL '5 minutes'
   OR prev_error IS NULL;

8. 跨数据库去重方案

不同数据库的特殊语法处理：

8.1 MySQL vs PostgreSQL

8.2 SQL Server的特别优化

sql复制-- 使用TOP WITH TIES实现优雅去重
SELECT TOP 1 WITH TIES *
FROM products
ORDER BY ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC);

9. 去重后的数据验证

完成去重后必须验证数据质量：

sql复制-- 检查去重前后记录数变化是否合理
SELECT 
  (SELECT COUNT(*) FROM original_table) AS before_count,
  (SELECT COUNT(*) FROM deduplicated_table) AS after_count,
  (SELECT COUNT(DISTINCT hash_key) FROM original_table) AS distinct_count;

-- 验证没有数据丢失
SELECT COUNT(*) 
FROM original_table o
WHERE NOT EXISTS (
  SELECT 1 FROM deduplicated_table d 
  WHERE d.id = o.id
);

10. 实战中的血泪教训

1. 索引陷阱：曾为去重字段创建了复合索引，但忘记包含排序字段，导致窗口函数全表扫描

2. NULL值灾难：某次去重时忽略了NULL处理，导致本应合并的客户记录被重复计算

3. 事务隔离问题：在去重过程中源表被修改，最终得到部分脏数据

4. 内存爆炸：低估了DISTINCT的内存消耗，导致生产数据库OOM崩溃

终极建议：任何重要去重操作前，先用EXPLAIN分析执行计划，在小规模样本数据上验证结果，并考虑使用WHERE条件先缩小处理范围