股海求生1. MySQL数据去重的核心场景与价值
数据去重是数据库操作中最基础也最频繁的需求之一。在实际业务中，我们常遇到以下几种典型场景：
- 用户行为日志表中存在重复记录需要清洗
- 多数据源合并时产生的重复条目
- 数据迁移过程中意外生成的冗余数据
- 统计报表需要获取唯一值列表
以电商平台为例，用户可能因网络问题重复提交订单，这时就需要识别并处理orders表中的重复记录。我曾处理过一个案例：某促销活动期间，由于系统重试机制导致约15%的订单数据重复，正是通过合理的去重方案挽回了大量存储空间和计算资源。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 基础去重方案：DISTINCT关键字
2.1 基本语法与原理
sql复制SELECT DISTINCT column1, column2
FROM table_name
WHERE conditions;
DISTINCT的工作原理是在内存中创建临时哈希表，通过比对哈希值来过滤重复行。当执行包含DISTINCT的查询时：
- MySQL会为结果集创建临时表
- 对指定列计算哈希值
- 通过哈希冲突检测判断是否重复
注意：DISTINCT作用于所有选择的列，不是仅针对第一个列
2.2 性能优化实践
在500万条记录的user_logs表测试中：
- 对单列去重耗时约1.2秒
- 三列组合去重耗时升至3.8秒
优化建议：
- 只为必要的列添加DISTINCT
- 配合WHERE条件先过滤数据范围
- 对常用去重列建立合适索引
sql复制-- 优化案例：先按日期过滤再去重
SELECT DISTINCT user_id, action_type
FROM user_logs
WHERE log_date > '2023-01-01';
3. 分组去重方案：GROUP BY
3.1 基础实现方式
sql复制SELECT column1, column2
FROM table_name
GROUP BY column1, column2;
与DISTINCT的区别：
- GROUP BY可以配合聚合函数使用
- 执行计划通常更高效
- 结果集排序方式不同
3.2 高级应用技巧
在数据分析场景中，我们常需要：
sql复制-- 获取每个分类的最新记录
SELECT product_id, MAX(create_time) as last_time
FROM products
GROUP BY category_id;
-- 计算不重复用户数
SELECT COUNT(DISTINCT user_id)
FROM orders;
实测对比：
- 在1000万数据量下，GROUP BY比DISTINCT快约30%
- 但内存消耗高出约15%
4. 行号去重方案：ROW_NUMBER()
4.1 窗口函数实现
MySQL 8.0+版本支持：
sql复制WITH deduplicated AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY column1, column2
ORDER BY create_time DESC
) AS rn
FROM table_name
)
SELECT * FROM deduplicated WHERE rn = 1;
4.2 复杂场景解决方案
处理数据仓库中的SCD（缓慢变化维）问题时：
sql复制-- 保留每个客户最新版本的记录
WITH customer_versions AS (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY version DESC
) AS row_num
FROM dim_customers
)
SELECT * FROM customer_versions
WHERE row_num = 1;
性能注意事项：
- 大表建议配合分区字段使用
- 排序字段要有索引支持
- 内存不足时可调整sort_buffer_size
5. 实战性能对比测试
在4核8G的MySQL 8.0环境测试：
| 方法 | 100万数据(ms) | 1000万数据(ms) | 内存占用(MB) |
|---|---|---|---|
| DISTINCT | 320 | 4200 | 120 |
| GROUP BY | 280 | 3800 | 150 |
| ROW_NUMBER() | 450 | 5200 | 300 |
关键发现：
- 简单场景优先用GROUP BY
- 需要保留特定记录时用ROW_NUMBER()
- 小数据量差异不明显
6. 特殊场景处理方案
6.1 大表去重优化
对于10亿级数据表：
- 采用分批次处理
sql复制-- 按ID范围分批
DELETE t1 FROM huge_table t1
INNER JOIN (
SELECT MIN(id) as keep_id, duplicate_key
FROM huge_table
GROUP BY duplicate_key
HAVING COUNT(*) > 1
) t2
ON t1.duplicate_key = t2.duplicate_key
AND t1.id != t2.keep_id
WHERE t1.id BETWEEN 1 AND 1000000;
- 使用临时表交换方式
sql复制-- 创建去重后的临时表
CREATE TABLE temp_table LIKE original_table;
INSERT INTO temp_table
SELECT * FROM original_table
GROUP BY duplicate_columns;
-- 原子替换
RENAME TABLE original_table TO old_table,
temp_table TO original_table;
6.2 JSON数据去重
处理JSON字段中的重复元素：
sql复制-- 提取JSON数组去重
SELECT
id,
JSON_REMOVE(
json_column,
JSON_UNQUOTE(
REPLACE(
JSON_SEARCH(
JSON_ARRAY(
SELECT DISTINCT JSON_EXTRACT(json_column, '$[*]')
),
'one',
JSON_EXTRACT(json_column, CONCAT('$[', n, ']'))
),
'"',
''
)
)
) AS deduplicated_json
FROM json_table
CROSS JOIN (
SELECT 0 AS n UNION SELECT 1 UNION ...
-- 生成足够多的索引数字
) AS numbers
WHERE n < JSON_LENGTH(json_column);
7. 常见错误与解决方案
-
DISTINCT与ORDER BY冲突
sql复制-- 错误示例 SELECT DISTINCT department, name FROM employees ORDER BY salary DESC; -- 正确方式 SELECT department, name, salary FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) as rn FROM employees ) t WHERE rn = 1; -
GROUP BY遗漏非聚合列
sql复制-- 错误示例（SQL模式非ONLY_FULL_GROUP_BY时） SELECT product_id, product_name, COUNT(*) FROM orders GROUP BY product_id; -- 正确方式 SELECT product_id, MAX(product_name), COUNT(*) FROM orders GROUP BY product_id; -
窗口函数性能陷阱
sql复制-- 低效写法（全表排序） SELECT *, ROW_NUMBER() OVER (ORDER BY create_time) FROM huge_table; -- 优化方案（利用索引） SELECT *, ROW_NUMBER() OVER (ORDER BY indexed_column) FROM huge_table;
8. 技术选型决策树
根据实际需求选择方案：
- 只需要唯一值列表 → DISTINCT
- 需要聚合计算 → GROUP BY
- 需要保留特定版本记录 → ROW_NUMBER()
- 超大数据量 → 分批处理+临时表
- JSON/特殊格式数据 → 自定义函数处理
在最近的数据迁移项目中，我们综合使用了这些技术：
- 先用ROW_NUMBER()识别最新版本数据
- 再用GROUP BY计算关键指标
- 最后用DISTINCT生成维度表
这种组合方案使处理时间从预估的8小时缩短到2小时。