MySQL用INSERT...ON DUPLICATE KEY UPDATE、SQL Server用MERGE、PostgreSQL用INSERT...ON CONFLICT均可原生实现upsert；核心前提是唯一约束匹配、避免竞态、注意语法限制与事务控制。
MySQL 中用 INSERT ... ON DUPLICATE KEY UPDATE 最简实现
只要表有主键或唯一索引，就能一条语句搞定“存在则更新，否则插入”，不用写存储过程也行。这是 MySQL 原生支持的语法，性能好、原子性强。
常见错误是没建唯一约束就直接用——ON DUPLICATE KEY UPDATE 依赖的是 PRIMARY KEY 或 UNIQUE 索引触发，否则永远走插入分支。
- 确保目标字段（如
user_id或email）上有UNIQUE约束 - 更新部分不能引用未在
VALUES()中明确给出的列，比如UPDATE name = VALUES(name), updated_at = NOW()合法；但updated_at = updated_at + 1会报错 - 如果想在更新时获取影响行数（区分是插入还是更新），可用
ROW_COUNT()：插入返回 1，更新返回 2
INSERT INTO users (id, name, email) VALUES (123, 'Alice', 'a@b.com') ON DUPLICATE KEY UPDATE name = VALUES(name), email = VALUES(email), updated_at = NOW();
SQL Server 用 MERGE 语句处理 upsert
MERGE 是 SQL Server 的标准 upsert 方式，逻辑清晰但语法稍重，容易因匹配条件写错导致全表更新或死锁。
最常踩的坑是 ON 子句里用了非 SARGable 条件（比如 ON UPPER(a.email) = UPPER(@email)），会导致索引失效、性能骤降；还有漏写 WHEN NOT MATCHED 或 WHEN MATCHED 分支，语句直接报错。
-
USING必须是单行源（如(VALUES (@id, @name)) AS src(id,name)），不能直接用变量列表 -
ON匹配条件必须能走索引，建议只用等值比较，且字段类型一致（避免隐式转换） - 更新操作中禁止修改
ON子句涉及的列，否则可能触发无限循环（SQL Server 会报错The MERGE statement attempted to UPDATE or DELETE the same row more than once）
MERGE users AS tgt USING (VALUES (@id, @name, @email)) AS src(id, name, email) ON tgt.id = src.id WHEN MATCHED THEN UPDATE SET name = src.name, email = src.email, updated_at = GETDATE() WHEN NOT MATCHED THEN INSERT (id, name, email, created_at) VALUES (src.id, src.name, src.email, GETDATE());
PostgreSQL 用 INSERT ... ON CONFLICT 替代存储过程
PostgreSQL 从 9.5 开始支持 ON CONFLICT，比 MERGE 更轻量，也比手写 SELECT + IF EXISTS 更安全——它天然避免竞态条件。
注意 ON CONFLICT 的冲突目标必须是索引表达式本身，不能是函数结果。比如你建了唯一索引 CREATE UNIQUE INDEX idx_email_lower ON users ((lower(email)));，那 ON CONFLICT (lower(email)) 才合法，写成 ON CONFLICT (email) 就不匹配。
- 冲突目标可以是列名、列组合，也可以是索引表达式，但必须和唯一约束定义完全一致
-
DO NOTHING和DO UPDATE二选一，不能共存；若要条件更新（比如只更新非空值），在SET后加WHERE - 更新子句中可用
EXCLUDED表引用本次插入的值，比如SET name = EXCLUDED.name
INSERT INTO users (id, name, email) VALUES (123, 'Alice', 'a@b.com') ON CONFLICT (id) DO UPDATE SET name = EXCLUDED.name, email = EXCLUDED.email, updated_at = NOW();
真需要存储过程？注意事务与异常边界
只有当 upsert 逻辑复杂到需调用其他 SP、记录日志、或跨多表联动时，才值得封装成存储过程。否则纯增加维护成本和执行开销。
最容易被忽略的是异常后事务状态：比如 PostgreSQL 的 ON CONFLICT 在冲突时不会抛异常，但你在存储过程中手动 SELECT 判断是否存在再分叉，一旦并发高，SELECT 和后续 INSERT/UPDATE 之间就会有窗口期，导致重复插入或丢失更新。
- 所有 upsert 类型的存储过程，开头必须显式
BEGIN TRANSACTION（SQL Server）或BEGIN（PG/MySQL），结尾配对COMMIT - MySQL 存储过程中不能直接用
ON DUPLICATE KEY UPDATE作为独立语句，必须包裹在INSERT里——有人误写成IF EXISTS (...) THEN UPDATE ... ELSE INSERT ...，这在并发下不可靠 - SQL Server 的
MERGE在存储过程中若没加WITH (HOLDLOCK)提示，可能引发死锁，尤其在高并发更新同一行时
真正难的不是语法，而是确认“存在”的判定依据是否和索引定义严格一致，以及并发场景下有没有隐式的竞态窗口——这些细节不压到执行计划和锁行为层面，光看代码很难发现。
