老李校长1. MySQL数据去重的核心场景与挑战
数据去重是数据库操作中最基础却最频繁的需求之一。在我处理过的电商订单系统中，仅上个月就遇到17次需要清洗重复数据的案例——从用户提交的重复订单到商品SKU信息重复入库。MySQL作为最广泛使用的开源关系型数据库，提供了多种去重方式，但每种方法在性能、适用场景上存在显著差异。
实际工作中常见的去重场景包括：
- 数据迁移时源表存在重复记录
- 应用程序逻辑缺陷导致重复提交
- 分布式系统最终一致性产生的重复数据
- 日志表因重试机制产生的重复条目
关键认知：去重操作的成本与表数据量呈指数级关系。在500万行以上的表中，不当的去重方法可能导致数据库长时间不可用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 基础去重方案：DISTINCT关键字的正确用法
2.1 DISTINCT的语法本质
SELECT DISTINCT column1, column2 FROM table是最直观的去重方式，但90%的开发者没有真正理解其工作原理。DISTINCT并非简单的"过滤重复"，而是对查询结果集执行排序后扫描，通过比较相邻行实现去重。
sql复制-- 典型用法（单字段）
SELECT DISTINCT department_id FROM employees;
-- 多字段组合去重
SELECT DISTINCT first_name, last_name FROM customers;
2.2 性能陷阱与优化方案
在8核16G的测试环境中，对1000万行数据执行DISTINCT查询：
| 字段数 | 无索引耗时 | 有索引耗时 |
|---|---|---|
| 1 | 4.2s | 0.8s |
| 3 | 7.8s | 1.5s |
| 5 | 12.4s | 3.2s |
优化建议：
- 仅为DISTINCT涉及的列创建复合索引
- 配合WHERE条件缩小处理范围
- 避免在DISTINCT中使用BLOB/TEXT类型
血泪教训：曾有个生产事故——开发者在DISTINCT中使用JSON字段，导致全表扫描耗时47分钟。切记：DISTINCT不适合处理大文本字段。
3. 分组去重：GROUP BY的进阶技巧
3.1 GROUP BY的去重原理
GROUP BY通过创建哈希表实现分组，天然具有去重效果。与DISTINCT相比，它更适合需要聚合计算的场景：
sql复制-- 基础去重
SELECT user_id FROM orders GROUP BY user_id;
-- 去重同时获取最新记录
SELECT product_id, MAX(create_time)
FROM inventory
GROUP BY product_id;
3.2 高性能分组配置
通过调整MySQL参数可显著提升GROUP BY性能：
sql复制-- 查看当前配置
SHOW VARIABLES LIKE '%group%';
-- 关键参数设置（需重启）
SET SESSION sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO';
SET SESSION group_concat_max_len = 1000000;
3.3 与HAVING的配合使用
HAVING子句可以在分组后进一步过滤：
sql复制-- 找出重复次数大于3的记录
SELECT email, COUNT(*) as cnt
FROM users
GROUP BY email
HAVING cnt > 3;
4. 窗口函数方案：ROW_NUMBER()的现代解法
4.1 窗口函数优势分析
MySQL 8.0+引入的窗口函数提供了最灵活的去重方式，特别适合需要保留特定行的情况：
sql复制-- 为每组重复数据添加行号标记
SELECT *,
ROW_NUMBER() OVER(PARTITION BY product_code ORDER BY update_time DESC) as rn
FROM product_versions;
4.2 实际应用模板
保留每组最新记录的完整方案：
sql复制WITH ranked_data AS (
SELECT *,
ROW_NUMBER() OVER(PARTITION BY user_id, session_id ORDER BY event_time DESC) as rn
FROM user_events
)
SELECT * FROM ranked_data WHERE rn = 1;
4.3 性能对比测试
在相同测试环境下处理100万条日志数据：
| 方法 | 执行时间 | 内存消耗 |
|---|---|---|
| DISTINCT | 1.2s | 320MB |
| GROUP BY | 0.9s | 280MB |
| ROW_NUMBER() | 1.8s | 410MB |
| ROW_NUMBER()+CTE | 2.1s | 450MB |
结论：虽然窗口函数消耗更多资源，但其灵活性无可替代。对于复杂去重逻辑，性能代价是值得的。
5. 特殊场景解决方案
5.1 大表去重实践
当表数据量超过内存容量时，可采用分批次处理：
sql复制-- 创建临时表存储去重结果
CREATE TABLE deduplicated LIKE original_table;
-- 分批处理（每次50万条）
INSERT INTO deduplicated
SELECT * FROM original_table
WHERE id BETWEEN 1 AND 500000
GROUP BY [去重字段];
-- 后续批次处理...
5.2 重复数据删除操作
物理删除重复记录的完整流程：
sql复制-- 步骤1：创建临时表存储要保留的ID
CREATE TEMPORARY TABLE keep_ids AS
SELECT MIN(id) as id
FROM duplicate_table
GROUP BY [去重字段];
-- 步骤2：执行删除
DELETE FROM duplicate_table
WHERE id NOT IN (SELECT id FROM keep_ids);
-- 步骤3：重建索引
ALTER TABLE duplicate_table ENGINE=InnoDB;
6. 方案选型决策树
根据你的具体场景选择最佳方案：
- 简单单列去重 → DISTINCT
- 需要聚合计算 → GROUP BY
- 保留特定行记录 → ROW_NUMBER()
- 超大数据量 → 分批处理+临时表
- 需要物理删除 → 事务隔离删除法
在金融交易系统中，我推荐使用ROW_NUMBER()方案。虽然性能不是最优，但能精确控制保留哪条记录，这对数据一致性至关重要。某次系统升级中，我们通过PARTITION BY transaction_id ORDER BY audit_time DESC成功修复了因网络抖动产生的重复交易记录。