在关系型数据库的数据写入过程中，主键冲突是开发人员经常遇到的错误之一。它的本质是主键唯一性约束被打破，INSERT语句在进入数据库引擎时就已经被判定无法执行。面对这种错误，很多人会直接改用UPDATE，但业务逻辑往往要求“有则更新，无则插入”，这时就需要一种兼顾两种行为的操作，也就是UPSERT。
一、主键冲突的典型场景
主键冲突通常发生在两类场景。第一类是并发写入，多个请求同时向同一张表插入相同主键的数据，例如用户连续点击提交按钮导致订单号重复。第二类是数据同步，当外部数据源和本地表存在重叠记录时，INSERT通常会因为没有处理唯一键约束而失败。
下面这段SQL演示了典型的主键冲突。假设表结构包含主键id，先插入一条id为1的记录，再次插入相同id时数据库会抛出错误。
INSERT INTO user_info (id, name, email) VALUES (1, '张三', 'zhangsan@ipipp.com'); -- 第二次执行同一语句，id=1已存在，触发主键冲突 INSERT INTO user_info (id, name, email) VALUES (1, '李四', 'lisi@ipipp.com');
从错误信息中可以看到，数据库明确提示Duplicate entry或者类似的违反主键约束信息。如果不做任何处理，程序会停止执行，在批量插入场景中还可能导致整个事务回滚。所以主键冲突并不仅仅是报错，它直接影响业务的可用性和数据一致性。
二、从INSERT到UPSERT：思路的转变
在处理主键冲突时，许多初期的方案是“先查询，再判断”。也就是先执行SELECT，若结果为空则INSERT，否则执行UPDATE。这种逻辑在单线程环境下可以工作，但在高并发场景下存在时间窗口，两个请求可能同时查询到“不存在”，随后都执行INSERT，依然会导致冲突。这种问题称为竞态条件。
UPSERT则是一种原子操作，它把“插入”和“更新”打包成一个整体，数据库会在执行过程中判断记录是否存在，存在则更新，不存在则插入，整个过程对并发环境是安全的。从应用层来看，只需要一条SQL即可完成原本需要多步逻辑才能完成的工作。
-- 传统做法：先查询，再决定插入还是更新 SELECT COUNT(*) FROM user_info WHERE id = 1; -- 若count为0，执行插入 -- INSERT INTO user_info (id, name, email) VALUES (1, '王五', 'wangwu@ipipp.com'); -- 若count大于0，执行更新 -- UPDATE user_info SET name = '王五', email = 'wangwu@ipipp.com' WHERE id = 1;
这段代码用注释说明逻辑，但实际开发中它还面临另一个问题：组合条件复杂时，SELECT和后续语句无法保证在同一事务内，数据库隔离级别也会影响结果。UPSERT将这一判断交给数据库，减少了应用层逻辑的复杂度，也让事务边界更加清晰。
三、主流数据库的UPSERT实现
虽然UPSERT是一种通用思想，但不同数据库的语法并不相同。开发人员需要根据实际使用的数据库选择匹配的写法。下面分别介绍MySQL、PostgreSQL和SQLite中的实现方式。
MySQL：INSERT ... ON DUPLICATE KEY UPDATE
MySQL提供ON DUPLICATE KEY UPDATE语句，它在INSERT语句后追加冲突处理逻辑。当插入的数据触发主键或唯一键冲突时，自动执行后面的UPDATE字段赋值。
INSERT INTO user_info (id, name, email) VALUES (1, '赵六', 'zhaoliu@ipipp.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);
注意，在MySQL 8.0及以上版本中，VALUES()函数被标记为废弃，推荐使用别名语法，例如AS new配合new.name进行引用。
PostgreSQL：INSERT ... ON CONFLICT
PostgreSQL使用ON CONFLICT子句，可以精确指定冲突目标。它的语法更灵活，支持在冲突时对指定列进行更新，也支持DO NOTHING。
INSERT INTO user_info (id, name, email) VALUES (1, '孙七', 'sunqi@ipipp.com') ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name, email = EXCLUDED.email;
其中EXCLUDED表示本次插入过程中未写入的数据集合，通过它可以引用待插入的新值，从而实现更新。
SQLite与SQL Server
SQLite同样支持ON CONFLICT，语法与PostgreSQL类似。而SQL Server则使用MERGE语句，写法相对繁琐。如果项目迁移到不同数据库，需要注意这些差异。
-- SQLite语法示例 INSERT INTO user_info (id, name, email) VALUES (2, '周八', 'zhouba@ipipp.com') ON CONFLICT(id) DO UPDATE SET name = excluded.name, email = excluded.email; -- SQL Server使用MERGE MERGE INTO user_info AS target USING (VALUES (2, '周八', 'zhouba@ipipp.com')) AS source (id, name, email) ON target.id = source.id WHEN MATCHED THEN UPDATE SET name = source.name, email = source.email WHEN NOT MATCHED THEN INSERT (id, name, email) VALUES (source.id, source.name, source.email);
从代码量可以看出，MERGE语法更复杂，在调试时需要注意语句结束符以及WHEN子句的顺序。
四、使用UPSERT的注意事项与性能优化
UPSERT虽然方便，但并不是万能钥匙。使用时需要注意几个细节。第一，主键冲突检测依赖于索引，如果表中存在多个唯一键，数据库需要明确冲突目标。在MySQL中，ON DUPLICATE KEY UPDATE会捕获任何唯一索引冲突，而不像PostgreSQL可以通过ON CONFLICT指定具体列。如果表中有多个唯一键，可能触发非预期更新，这一点需要特别警惕。
第二，批量UPSERT可以显著降低数据库交互次数。例如一次插入多条记录时，可以配合VALUES列表和ON DUPLICATE KEY UPDATE语句实现批量操作，但对于大批量数据，还需要考虑事务大小和锁竞争。
-- 批量UPSERT示例：一次处理多条记录 INSERT INTO user_info (id, name, email) VALUES (1, '吴九', 'wujiu@ipipp.com'), (2, '郑十', 'zhengshi@ipipp.com'), (3, '王十一', 'wangshiyi@ipipp.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email);
这段代码用一条SQL批量处理三条记录，冲突时更新name和email。执行计划会尽可能减少扫描次数，但需要注意的是，如果表数据量很大且存在二级索引，每次更新都会带来额外的索引维护开销。
此外，UPSERT中的更新时间字段也很常见。比如记录需要维护last_updated字段时，可以在冲突处理中加入当前时间戳。下面是一个同时更新业务数据和时间的例子。
INSERT INTO user_info (id, name, email, updated_at) VALUES (1, '陈十二', 'chen@ipipp.com', CURRENT_TIMESTAMP) ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = CURRENT_TIMESTAMP;
这种写法可以保证每次冲突发生时，时间戳都会刷新，适用于订单状态同步、用户资料更新等场景。
UPSERT操作在数据同步、批量导入和接口幂等设计中扮演着重要角色。相比传统的SELECT+INSERT/UPDATE，它能减少竞态条件、降低网络往返次数，并让代码逻辑更简洁。不过，在具体使用时仍需结合数据库特性，选择正确的语法，并对批量场景进行充分的性能测试。掌握主键冲突的处理策略，是编写健壮SQL的基本功。