3个经典坑让你掉坑里：一文搞懂SQL重复值处理 打开官方文档，关于去重的章节往往长达数页，满屏的 DISTINCT、ROW_NUMBER()、EXISTS 术语，让人看得头皮发麻。你只想快速解决报表里数据翻倍的问题，结果在文档迷宫里转了半小时还没找到最适配你场景的方案。 别急，我们直接切入正题。今天不聊虚的，只讲实战中踩过的血泪坑。很多开发者以为处理重复值就是加个 DISTINCT，但在高并发、大数据量或特定业务逻辑下，这种简单粗暴的做法不仅性能拉胯，还可能引发数据一致性灾难。Stack Overflow 上关于“为什么我的去重查询变慢了”的问题高达数百个，核心原因往往不是语法错误，而是对底层执行机制的误解。 坑的现象：看似正常的去重，实则隐患重重 在业务开发中，处理重复值通常出现在两个场景：一是查询结果需要唯一性展示，二是数据写入前需要校验唯一性。最常见的现象是：你写了一个简单的 SELECT DISTINCT id, name FROM table，测试环境跑起来没问题，一上生产环境，响应时间从 50ms 飙升到 5s，甚至导致数据库连接池耗尽。 更隐蔽的坑在于“伪去重”。比如你在订单表中，同一个用户同一时间下了两单，但订单号不同。你按 user_id 和 create_time 去重，结果发现丢掉了真实存在的两笔不同订单。这时候你会发现，去重的字段组合根本没覆盖到真正的业务唯一键。 还有一种典型报错：在 INSERT 操作中，你以为加了 IGNORE 或者 ON DUPLICATE KEY UPDATE 就能一劳永逸，结果因为索引缺失，导致重复数据照样入库，只是没有报错而已。这种静默失败比报错更可怕，因为它污染了数据，且难以追溯。 根本原因：执行计划与索引的错位 为什么 DISTINCT 会慢？因为它在底层通常意味着“排序”或“哈希去重”。如果数据量小，内存能装下，速度很快；但如果数据量大，MySQL 或 PostgreSQL 必须使用磁盘临时文件进行排序，I/O 开销呈指数级上升。 很多开发者忽略了一个关键点：去重的效率完全取决于去重字段的索引情况。如果你按 email 去重，但表上只有主键 id 的索引，数据库必须全表扫描，把每一行的 email 拿出来比对，这是最昂贵的操作。 另一个根本原因是业务逻辑与数据模型的错配。很多表设计时没有建立合适的唯一约束，导致应用层需要手动去重。数据库是唯一性约束的最后一道防线，如果不在数据库层面通过 UNIQUE KEY 保证，仅靠应用层代码去重，在分布式环境下极易出现竞态条件（Race Condition），即两个请求同时通过去重检查，同时插入，最终导致数据重复。 Stack Overflow 上高赞回答经常指出：80% 的去重性能问题，都可以通过添加合适的联合索引来解决，而不是优化 SQL 语句本身。 正确写法对比：拒绝“一刀切” 处理重复值没有银弹，必须根据场景选择策略。下面对比两种最常见的场景：查询去重 vs 写入去重。 场景一：查询结果去重（Read Path） 错误写法：盲目使用 DISTINCT -- 假设我们需要获取所有不重复的用户ID和姓名 -- 表结构：users (id, name, email, created_at) -- 索引：PRIMARY KEY (id)SELECT DISTINCT id, name FROM users;问题分析：DISTINCT 会对 (id, name) 进行全量排序去重。 如果 id 是主键，理论上 id 本身就是唯一的，加上 DISTINCT 是多余的操作，数据库引擎会额外进行哈希或排序计算，浪费 CPU 和内存。 如果去重字段不是主键，且没有索引，性能极差。正确写法：利用索引覆盖或子查询 -- 方案A：如果只需要主键，直接查，无需 DISTINCT SELECT id, name FROM users;-- 方案B：如果确实需要按非唯一字段去重，且该字段有索引 -- 假设我们按 email 去重，且 email 有唯一索引 SELECT id, name FROM users WHERE email IN (SELECT MIN(id) FROM users GROUP BY email );进阶技巧： 使用 GROUP BY 配合聚合函数（如 MIN, MAX）往往比 DISTINCT 更高效，因为 GROUP BY 可以利用索引直接获取分组后的最小/最大值，避免了全量排序。在 MySQL 中，如果 email 有索引，GROUP BY email 可以利用索引顺序扫描，速度远快于 DISTINCT。 场景二：数据写入去重（Write Path） 错误写法：先查后插（Check-Then-Act） # Python 伪代码 def insert_user(email, name):# 第一步：查询是否存在exists = db.query(SELECT 1 FROM users WHERE email = %s, email)if not exists:# 第二步：插入db.execute(INSERT INTO users (email, name) VALUES (%s, %s), email, name)else:# 第三步：更新db.execute(UPDATE users SET name = %s WHERE email = %s, name, email)问题分析： 这是典型的竞态条件漏洞。在多线程或多进程环境下，两个线程可能同时执行“查询”，都发现不存在，然后同时执行“插入”。如果数据库没有唯一约束，结果就是插入了两条重复记录。即使加了事务，隔离级别（如 Read Committed）也可能导致幻读问题。 正确写法：依赖数据库唯一约束 + 异常处理或 UPSERT -- 方案A：利用数据库唯一约束，捕获异常 -- 前提：users 表必须建立 UNIQUE KEY (email)INSERT INTO users (email, name) VALUES ('test@example.com', 'Test User'); -- 如果抛出 Duplicate Key Error，则执行更新逻辑-- 方案B：使用 UPSERT (MySQL 示例) INSERT INTO users (email, name) VALUES ('test@example.com', 'Test User') ON DUPLICATE KEY UPDATE name = VALUES(name);-- 方案C：使用 PostgreSQL 示例 INSERT INTO users (email, name) VALUES ('test@example.com', 'Test User') ON CONFLICT (email) DO UPDATE SET name = EXCLUDED.name;核心区别： UPSERT 语句是原子的，数据库在引擎层面保证了检查与写入的原子性，彻底规避了竞态条件。这是处理写入去重的唯一推荐方案。 复现与修复代码：实战演练 让我们用一个具体的 Python + MySQL 案例来复现并修复上述问题。 复现竞态条件 假设我们有一个高并发的注册接口，100 个线程同时尝试插入同一个邮箱。 错误代码（无唯一约束 + 先查后插）： import threading import mysql.connectordef register_user(email):conn = mysql.connector.connect(...)cursor = conn.cursor()# 查询cursor.execute(SELECT COUNT(*) FROM users WHERE email = %s, (email,))count = cursor.fetchone()[0]if count == 0:# 模拟网络延迟，放大竞态窗口import timetime.sleep(0.1)cursor.execute(INSERT INTO users (email) VALUES (%s), (email,))conn.commit()cursor.close()conn.close()# 启动100个线程 threads = [threading.Thread(target=register_user, args=(same@email.com,)) for _ in range(100)] for t in threads:t.start() for t in threads:t.join()# 结果：users 表中可能有几十条重复记录修复方案 步骤 1：添加唯一索引 ALTER TABLE users ADD UNIQUE KEY idx_email (email);步骤 2：修改代码为 UPSERT 或异常捕获 import threading import mysql.connector import loggingdef register_user_safe(email):conn = mysql.connector.connect(...)cursor = conn.cursor()try:# 使用 INSERT ... ON DUPLICATE KEY UPDATE# 注意：这里假设 id 是自增主键，我们只关心 email 唯一cursor.execute(INSERT INTO users (email) VALUES (%s)ON DUPLICATE KEY UPDATE id = LAST_INSERT_ID(id), (email,))conn.commit()except mysql.connector.IntegrityError as e:# 捕获其他可能的唯一约束冲突logging.warning(fDuplicate entry detected: {e})finally:cursor.close()conn.close()# 重新运行100个线程 # 结果：users 表中只有 1 条记录，且 ID 正确关键点解析： ON DUPLICATE KEY UPDATE id = LAST_INSERT_ID(id) 这一行非常关键。它确保了即使发生更新操作，LAST_INSERT_ID() 也能返回已存在记录的 ID，而不是 0 或新的自增 ID。这在需要获取主键 ID 的场景下至关重要。 规避建议：从设计源头解决问题 处理重复值，治标不如治本。以下是几条血泪换来的建议：唯一约束是底线：任何业务上认为“唯一”的字段组合，都必须在数据库层面建立 UNIQUE KEY。不要相信应用层代码，不要相信事务隔离级别。数据库约束是唯一可靠的屏障。 索引即性能：去重查询的性能 90% 取决于索引。如果你经常按 status 和 date 去重，就建立 (status, date) 的联合索引。记住最左前缀原则，索引字段顺序要与查询条件一致。 避免过度去重：在 SELECT 中，如果去重字段包含主键，DISTINCT 是多余的，直接删除。如果去重字段没有业务意义，考虑是否真的需要去重，或者是否可以通过 GROUP BY 聚合来替代。 监控重复数据：建立定期扫描任务，检查关键表的重复数据。可以使用如下 SQL 快速定位：SELECT email, COUNT(*) as cnt FROM users GROUP BY email HAVING cnt 1 ORDER BY cnt DESC LIMIT 10;分库分表下的去重：在分布式数据库或分库分表场景下，全局唯一性更难保证。推荐使用 UUID 或雪花算法（Snowflake）生成全局唯一 ID，而不是依赖自增 ID。对于业务字段（如 email），仍需在各分片建立局部唯一索引，并在应用层或中间件层做全局校验。重复值处理看似简单，实则涵盖了数据库原理、并发控制、索引优化等多个维度。不要低估它的复杂度，也不要被官方文档的冗长吓退。抓住“索引”和“原子性”这两个核心，就能解决 90% 的重复值问题。 你在项目中遇到最棘手的重复值场景是什么？是查询性能问题，还是并发写入冲突？你更常用哪种写法？评论区交流，看看有没有更好的解决方案。